Wayland 真的毁掉一切了吗？
Wayland X11
![](/data/attachment/album/202312/29/145333us6izt3xtvul3lu7.jpg)


“[Wayland 毁掉一切！](/article-16520-1.html)”有些人已经看过了这篇 Probonopd 批评 Wayland 的略有名气的文章。Probonopd 是 AppImage 开发者的核心者之一，他批评 Wayland 并非 X11 的直接替代品。他在 GitHub 上创建了一个 [新的仓库](https://github.com/probonopd/wayland-x11-compat-protocols/)，再次吸引了公众的目光，他希望为目前 Wayland 原生应用无法使用的功能创建协议。而这些功能是 Wayland 标准协议有意缺失的，但缺乏标准化意味着它们无法成为应用开发者可信赖的平台组成部分。


尽管开发者圈子里有人对此一笑置之，乃至嘲笑，但对于普通人来说，“Wayland 毁掉一切！”这句指责可能戳中要害，或者至少看起来有几分道理。因为从某种角度，Probonopd 是对的：Wayland 确实破坏了所有直接依赖 X11 功能的事物！


只是这种角度是错误的。


试想，如果我说：“Linux 让 Photoshop 无法工作，你还是应该坚持使用 Windows！”你该如何回应呢？你可能会说：“等等，问题的关键是 Photoshop 不支持 Linux！”你说得对，这是一个微妙且重要的区别，它将责任放在了正确的位置。因为即使是 Linux，也无法“不破坏” Photoshop；相反，Adobe 需要为其产品进行移植，只不过他们还没有做罢了。


对于 X11 和 Wayland，情况也同样适用。Wayland 并不是为了取代 X11 而设计的，就像 Linux 不是为了取代 Windows 而设计的一样。当我们从一个操作系统转到另一个时，有必要调整我们的期望，认清可能需要的改变。


尽管 Wayland 并非设计为 X11 的直接替代品，但它最终肯定会取代 X11。但这意味着它从一开始就打算比 X11 做得更少，而这是正确的。


### X11 是个糟糕的平台


在那些古老的日子里，X11 是个完整的开发平台。以 X11 为目标的应用程序可以使用 X11，通过内建的小部件工具包来进行 UI 绘制；借助自带的打印服务器打印文件；进行屏幕录屏；设定全局快捷键等等。这一切都远在我接触技术之前，但我感觉到，X11 要么是在最初就被设定为面向应用开发者的开发平台，要么在早期阶段迅速演变成了这样一个平台。


然而，情况并没有如预期那样发展。即使是以当时的标准而言，其内置的 UI 工具包看起来也很丑陋。那些请求同一资源的应用可能会互相冲突，破坏彼此的功能，除非卸载其中一个应用程序，否则根本无法修复。像打印这样的特性渐渐没落，因为将这样的功能放在窗口管理器里就是个错误，而后续的维护者也缺少必要的专业知识或兴趣去维护它。诸如此类，不一而足。


像 Qt 和 GTK 这样的 UI 工具包迅速崛起，以更适合用户和便于应用开发者定位的方式，接管了大多数此类应用平台程序的中间件职能。我们这里说的是九十年代中期，那已是相当久远的时代了。


*（当然，这样说可能有些不公平；人们抱怨 Wayland 缺少的其实并不是打印服务器。实际上，更多的是关于应用能否设置自定义窗口图标，以及移动自身的窗口。这些都是非常困难的情况；Wayland 上没有这些功能，理由就是这些功能在 X11 中被滥用，导致了难以解决的问题。要将这些功能移植到 Wayland 并非易事，涉及很多的权衡决定。）*


### Linux 并非一个平台


然而，UI 工具包的兴起无疑导致了应用程序的格局变得支离破碎。现在，FOSS 应用程序开发者不再为一个目标（X11）进行开发，而是为 Qt、GTK 或其他工具进行开发，从而我们看到了了大量的“KDE 应用” 和 “GNOME 应用”。是的，这些应用可能在其他平台里也能运行，但很明显，它们是在哪个平台和工具包上开发的，在哪个平台和工具包上运行效果最好。在其他平台运行时，它们可能看起来感觉很奇怪，或者某些功能可能不好用或根本无法使用。


这就是我们今天的现状。没有人会专门去编写一个 “X11 应用”；他们的应用可能会采用 X11 的某些特性，但这只是因为没有更好的替代方案，而实际上，在应用的 99.9% 的功能实现中，他们会选择 Qt、GTK、KDE Frameworks 或者其他相似工具。


这给我们带来了一个潜在的棘手问题： Linux 也不是一个真正的平台，在成为一个平台方面它并不比 X11 更成功。因为几乎没人会专门编写一个“Linux 应用”；直接调用原始的 Linux 内核系统通常是没必要的，因为无论你使用的是什么 UI 工具包，都会封装这些功能，并且将其抽象到工具包所支持的所有各种平台上。这样一来，工具包就能确保这些功能在 Linux 平台也都能顺利工作。


### 真正的平台


那么，对于跨桌面的互操作性而言，所有希望都已经破灭了吗？不，实际上现在的前景比以往任何时候都要美好！因为如今事实上出现了一个新兴的平台；如果你需要，它可以将各种应用工具包都抽象化。我说的是 Portals、PipeWire，以及 Wayland 协议。


Probonopd 认为这些都是附加组件，不应该在系统上运行，但我认为他的这种观点并不站得住脚。提供全面功能的单体窗口服务器模式在几十年前就被证明是失败的。取而代之的是库和 API，每个 FOSS 开发者都可以合理预期在现代系统运行这些。


门户系统提供了一种标准化的方法，用于展示平台原生的打开或保存对话框、发送通知、以其他应用打开文档、打印文档、拍摄截图、录制屏幕、处理拖放操作、查看用户当前主题是亮色还是暗色，等等。在很多功能的实现上，门户系统都倚赖于 PipeWire，因此你可以预期 PipeWire 也会被安装。同时，你也可以期待大部分 Wayland 合成器 — 尤其是两个最重要的合成器 KWin 和 Mutter — 支持几乎所有公开标准化的 Wayland 协议。


我认为这就是平台：Portals + Wayland + PipeWire。很明显，并没有一个好记的名字来囊括这一切。? 或许我们可以叫它 PW<sup> 2</sup>。不过，如果你的应用程序以这些平台为目标，那么它几乎可以在所有现代 Linux 系统上运行。并且，Qt 和 GTK 这两个大型的 FOSS 工具包都为此提供了全面的支持。所以，使用你喜欢的任何 UI 工具包都可。


### 为何是现在？


我们最近听到越来越多关于这个话题的讨论，因为这个转型正在加速发展。X11 的维护者已经宣布终止对其的维护，而 Plasma 则开始默认采用 Wayland，GNOME 也是如此。Fedora 甚至完全放弃了对 X11 的支持。


我们现在正处于这样一个阶段，那些以前从未考虑过这个问题的人开始思考，并意识到他们的特定使用场景所需的所有组件都还没有到位。可这其实是好事！他们的意见被听取了，变化就有可能发生。我希望这一切能早点发生，但我们也要承认现实，我们还在路上，最近围绕远程控制、色彩管理、绘图板以及窗口布局等方面的提案和工作非常频繁。可能会有一个尴尬的阶段在等我们，直到所有需要的部分都到位。对于那些由于关键遗漏而备受困扰的人，我建议他们继续使用 X11，直至问题解决。没人会去阻止你（嗯，除了 Fedora，所以如果你确实无法适应，那就不要用 Fedora ?）。探索新事物应该是充满乐趣的，如果不是这样，那就转换一个角度再尝试吧。


### 结语


在这个语境下，“毁掉一切”或许可以更准确地表达为“还没完全移植所有事物”。这种移植是必要的，因为 Wayland 设计的目标聚焦于未来，而未来并不完全兼容我们过去所做的一切，因为事实证明，其中很多东西已经没有意义了。对于那些有意义的东西，我们已经提供了一个兼容层（XWayland），同时，任何需要深度系统集成的部分，一般都有一个解决的路径（如 Portal、Wayland 协议以及 PipeWire）或者正在积极的研发中。整个世界，都在发生变化！


*（题图：DA/d5a50347-47e0-472f-833b-58203196a743）*




---


via: <https://pointieststick.com/2023/12/26/does-wayland-really-break-everything/>


作者：[Nate Graham](https://pointieststick.com/contact/) 译者：[ChatGPT](https://linux.cn/lctt/ChatGPT) 校对：[wxy](https://github.com/wxy)


OK
I’ve written some [other posts](https://pointieststick.com/2023/09/17/so-lets-talk-about-this-wayland-thing/) on Wayland recently, and it’s time for another one! Feel free to skip it it you aren’t interested in a discussion of Wayland and platforms.

Many may be familiar with the now semi-famous [“Wayland breaks everything!”](https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277) document written by Probonopd–one of the core AppImage developers–panning Wayland because it isn’t a drop-in replacement for X11. And he’s in the news again for [a new Github repo](https://github.com/probonopd/wayland-x11-compat-protocols/) with the aspiration of creating protocols for functionality not currently available to Wayland-native apps that are intentionally missing in Wayland’s standardized protocols–which won’t work because lacking standardization means they won’t become a part of the platform that app developers can reliably target.

There’s a bit of chuckling and jeering over this in developer circles, but to regular people, the whole “Wayland breaks everything” charge might ring true, or at least seem like it contains a kernel of truth. Because from a certain perspective, he’s right: Wayland really does break everything that directly uses X11 functionality!

It’s just that this is the wrong perspective.

Look, if I said, “Linux breaks Photoshop; you should keep using Windows!” I know how you’d respond, right? You’d say “Wait a minute, the problem is that Photoshop doesn’t support Linux!” And you’d be right. It’s a subtle but important difference that puts the responsibility in the right place. Because there’s nothing Linux can do to ‘un-break’ Photoshop; Adobe needs to port their software, and they simply haven’t done so yet.

And it’s much the same with X11 and Wayland. Wayland wasn’t designed to be a drop-in replacement for X11 any more than Linux was designed to replace Windows. Expectations need to be adjusted to reflect the fact that some changes might be required when transitioning from one to the other.

Now, even though Wayland wasn’t designed to be a *drop-in* replacement for X11, it was certainly intended to *eventually* replace it. But this implies that it was intended from the start to do *less* than X11, and and that would be correct.

## X11 was a bad platform

In ye olden days, X11 was a whole development platform. Your app that targeted X11 could use X11 to draw its UI with a built-in widget toolkit; print documents with an included print server; record the screen; set global keyboard shortcuts; and so on. This is all way before my time, but I get the sense that X11 was either originally envisioned to be a development platform for app developers, or else quickly morphed into one during its early days.

It didn’t work out. The built-in UI toolkit looked horrendous, even for the standards of the time. Apps that requested the same resources could stomp on one another and break each others’ functionality in ways that were impossible to fix short of uninstalling one of the apps. Features like printing withered because a window manager was really the wrong place to put that functionality and its later maintainers lacked the needed expertise or interest to maintain it. And so on.

UI toolkits like Qt and GTK quickly rose up to take over most of this sort of app platform middleware in a way that worked much better for users and was easier to target for app developers. We’re talking about the mid 90s here; it was a long time ago.

(Of course this is slightly unfair; lacking a print server isn’t what people complain about being missing from Wayland. It’s more like things like apps able to set custom window icons and move their own windows. These are the really hard cases; they aren’t present on Wayland because they were commonly abused by apps on X11 to cause unsolvable problems. It’s not an easy thing and there are trade-offs involved in bringing them to Wayland.)

## Linux isn’t a platform

Anyway, the rise of UI toolkits necessarily fragmented the app landscape. Instead of developing for one target (X11), a FOSS app developer now developed for Qt, or GTK, or whatever, so we ended up with a lot of “KDE apps” and “GNOME apps.” Yes, these apps still probably worked elsewhere, but it was obvious what platform and toolkit they been developed to work best in. They might look and feel weird when run elsewhere, or certain features might not work well or at all.

And that’s where we remain today. Absolutely nobody writes an “X11 app”; their app may use functionality in X11 for something that there’s no better way to do, but the app will use Qt, GTK, KDE Frameworks, or whatever for 99.9% of its functionality.

It brings us to a potentially thorny topic: Linux isn’t really a platform either, any more than X11 succeeded at being one. Almost nobody writes a “Linux app”; making raw Linux kernel system calls is generally unnecessary because whatever UI toolkit you’re using wraps this functionality and abstracts it to all the different platforms that the toolkit supports. The toolkit ensures that it just happens to work on Linux too.

## The real platform

So is all hope lost for cross-desktop interoperability? No. In fact prospects are better than they have been in a long time! Because today there is in fact an emerging platform; something that abstracts away even the app toolkits if you want to roll that way. I’m talking about Portals, PipeWire, and Wayland protocols.

Probonopd pans these as bolt-ons that you shouldn’t have to have running on your system, but I think this isn’t realistic. The model of the monolithic window server that offers all functionality failed decades ago. In its place, we have libraries and APIs that every FOSS developers can reasonably expect a modern system to be running.

The portal system offers a standardized way to present platform-native open or save dialogs, send notifications, open documents in other apps, print documents, take screenshots, record the screen, handle drag-and-drop, see if the user’s active theme is light or dark, and much more. The portal system uses PipeWire under the hood for a lot of this stuff, so you can expect that to be installed as well. And you can also expect most Wayland compositors–most notably the two most important ones KWin and Mutter–to support pretty much all publicly standardized Wayland protocols.

I think *this* is the platform: Portals-and-Wayland-and-PipeWire. Clearly we need to come up with a better name. 🙂 Maybe PW2. But if your app targets these, it will run on pretty much every modern Linux system. And the big two FOSS toolkits of Qt and GTK both have cutting-edge support for all of it. So use whatever UI toolkit you like.

## Why now?

We’re hearing more about this recently because the transition is picking up steam. X11’s maintainers have announced an end to its maintenance. Plasma is going Wayland by default, following GNOME. Fedora is dropping X11 support entirely. We’re in the part of the transition where people who haven’t thought about it at all are starting to do so and realizing that 100% of the pieces needed for their specific use cases aren’t in place yet. This is good! Them being heard is how stuff happens. I wish it had happened sooner, but we are where we are, and there are a lot of recent proposals and work around things like remote control, color management, drawing tablet support, and window positioning. There will probably be an awkward period before all of these pieces are in place for all of the people. And for the those who really do suffer from showstopping omissions, I say keep using X11 until it’s resolved. No one’s stopping you (well, except for Fedora, so if this is you, don’t use Fedora. 🙂 The cutting edge should be fun! If it isn’t, try something else).

## Wrapping up

In this context, “breaking everything” is another perhaps less accurate way of saying “not everything is fully ported yet”. This porting is necessary because Wayland is designed to target a future that doesn’t include 100% drop-in compatibility with everything we did in the past, because it turns out that a lot of those things don’t make sense anymore. For the ones that do, a compatibility layer (XWayland) is already provided, and anything needing deeper system integration generally has a path forward (Portals and Wayland protocols and PipeWire) or is being actively worked on. It’s all happening!

I remember moving from DOS to Linux in the early ’90s and having the same reaction as all these people disliking Wayland. In DOS (which used the CPU in the real address mode) I was able to modify the interrupt vector table, write to any memory region I wanted including the memory used by other programs or the video memory. I even wrote assembler programs drawing lines and curves on the screen by writing directly to the video memory. The code was very simple to write.

Then I moved to Linux (it used the protected address mode) and everything was a lot more complicated. I could not easily port my “graphics” programs because I couldn’t write to the video memory anymore (I later found ways to do it but eventually figured better ways to draw on the screen). I couldn’t easily modify the interrupt vector table either! What a terrible OS Linux was!! Why would anyone prefer the protected mode approach with all its complications versus the simplicity of the real mode??

Several years later DOS was essentially abandoned in favor of Windows95 and it was goodbye real mode and thus my programs became obsolete.

Fast forward 20 more years, and I see the same thing with Wayland versus X11. Anyway, I am happy to see that, finally, Wayland is implementing the philosophy behind the protected mode and replacing the naive philosophy of X11.

LikeLiked by 1 person

I just realized, that Wayland “breaks” Firefox, or in other words, Wayland is not browser ready…

Since Firefox 121 went Wayland native, it stopped correctly raising to the foreground when a link is clicked in an external app (Thunderbird, document in Libre Office, etc.).

The bug started after Firefox update to 121 and other users can confirm it in Wayland. It happens on my system, on the other computer with Wayland as well. I checked system (Manjaro) in VirtualBox and could confirm the issue on Wayland with Plasma and Gnome, but not in X11.

My hope is, that it’s not a Wayland current limitation, but a faulty Wayland implementation of Firefox, but somehow I feel that it is Wayland itself.

For work, I frequently have to open sites or documents from links in mails or documents. The fact that I need to do an additional action of moving my cursor to the FF icon and clicking on it, is tiring and irritating if done many times. Especially, that earlier it was seamless and easy – click the link and the site or a document was ready on the foreground. It’s hard to get to use to the regression :(.

Chrome based browsers still use XWayand and have no problem with raising to the top after clicking a link.

This is one of many examples, where native Wayland windows are in disadvantage. Another one is LibreOffice (at least the version on Arch).

LikeLike

It’s a bug in the implementation either in Firefox, or in the app the link originated in, or both. This is working for me in all the origin apps I regularly use.

LikeLiked by 1 person

Which apps if I may ask? I tried links in Thunderbird (XWayland) and LibreOffice (flatpack, Wayland). Even if in other apps that have links would work correctly, I mostly need them to work from Thunderbird. Still, I would love to try to see if that changes anything.

I reported the bug to Mozilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=1873981

If this is a bug in Firefox Wayland implementation, there is a chance it will be fixed quicker than if it was a Wayland limitation, or at least I hope. With such big projects as Firefox, they probably get hundreds if not thousands of reports every day, so it may be hard to push through to the proper team. I already suggested forwarding it to people responsible for Wayland implementation, but will someone do it? I don’t know. At this point, I will be happy if my report will get duplicate flag, because it will mean that someone else reported it as well, and they may have a better luck, being earlier.

LikeLike

Wonderful writeup, sir.

LikeLiked by 1 person

“wayland breaks everything” is exactly the kind of philosophy that goes into MSFT development efforts, leading to decade old inaccuracies in Excel calculations because Gord forbid we push a breaking change to this 30 year old code base… ad nauseum…

LikeLike

I found this article because a conversation came up with a non-Linux programmer in which I explained why X11, despite being generally clunky and that I

wishI could replace, is still the protocol I use. Even more so after reading this and discovering that X11 is now definitely end-of-life, which is news to me. I’ve been living under a rock.I wanted to hear a different perspective, and this article was a good one! I agree that the attitude of “Breaking X11 apps is a good enough reason to never use Wayland” is a bad one. That being said, I’d like to offer a counterpoint as to why X11 still has a place on my system:

The PW^2 “platform” might not be ready for the individual window manager developer. Or at least, I wasn’t ready for it, back when I first considered switching sometime in 2020.

I maintain my own fork of the (in)famous suckless dwm. I enjoy doing so as a hobby- I expect no one else to use my windowing system, and I want to experiment with writing my own extensions for the sake of exploring UI design.

It has stuck to X11 for the reason of pragmatism: X11 is a giant piece of software that handles a lot of complex logic, allowing dwm to be small and hackable for the individual. Because the X11 APIs are standardised, even my little-windowing-manager-that-could can run any program built on X11. I’d heard talk on the suckless mailing list to that effect: That the API standard ought to have been more comprehensive, even if the reference implementation didn’t implement it all, so that the desired capabilities for a particular user could be built up using a modular system with a shared API.

All that being said, it seems that PW^2 has matured much more since my first attempt at switching away from X11 and PulseAudio four years ago. Portals, in particular, seems to solve my big gripes. Hearing that X11 ended maintenance for-real-this-time has me thinking that maybe it’s time for me to look back into the ecosystem. Thanks again for the article.

LikeLike