by jchw | 2025-06-19 14:05:08+00:00
> This is the core issue, it seems. The Wayland transition is kinda like if Volkswagen said "we're now going to stop making cars, and focus entirely on making the best gearbox possible". Well what are people that just want to get around going to do?

Even if it is a bit annoying, this pain is a temporary one. Users didn't really need to know what an X server is or how to use it, and likewise they don't really need to know what Wayland is... except for one thing, which is during this transition they need to know what the trade-offs are for "GNOME X11 Session" vs "GNOME Wayland Session" and so forth. But otherwise, neither of these things were meant to be marketed to end users in the first place. Unfortunately though, user's intuition is failing them: There is a much bigger difference between "GNOME Wayland Session" and "Plasma Wayland Session" than there is between "GNOME X11 Session" and "Plasma X11 Session", and it's not clear or obvious at all.

> I get that X11 just didn't have a future, but to me it seems the choices the Wayland developers made meant the replacement happened much slower than it could have. That is, we could have had a much better Linux desktop today than we do, had they made different choices.

To be honest, I don't know the answers. I think a lot of people see me routinely defending Wayland and think the reason is because I personally think it's wonderful, but actually I think Wayland is ugly and made many bad decisions. The wire protocol has no native 64-bit integers. I think that the GNOME folks are dumb for not accepting server-side decorations as a reality and figuring out how to make Mutter handle it, even if it involved working out out-of-process stuff for it. Trying to deal with the GTK/GNOME developers for trying to work on a problem was so frustrating I flat-out deleted my GNOME GitLab account. I also think that it is unfortunate that we already have a fair amount of cruft in the form of unstable, staging, ext, etc. protocols that are sometimes available and sometimes not. Even with all of that in mind, it's so blatantly obvious to me that Wayland is the future for Linux, at least right now. There's no better option emerging, and frankly there are no true deal-breakers with Wayland... Just challenges.

Admittedly, part of the reason why the case for Wayland feels relatively weak now is just because the X.org server got a lot more usable in the last decade or two. When I first jumped on Linux, the X11 server we used was XFree86. There was no hotplugging; if you wanted a new monitor or keyboard to work, you had to restart the X server. Once hotplugging was added, it was unstable for a long time and pretty routine for plugging in a monitor to crash. Multi-GPU situations are still pretty hackish though they do sort of work. In 2013, X11 worked on touchscreens, but it was extremely unstable, and it wasn't uncommon for things to get "stuck", or the X server to simply segfault when touching the screen. Until 2021, variable refresh rate was basically unusable for multi-head configurations, since the primary head drove the buffer flipping. The Linux graphics stack improvements with DRM and KMS became a part of the X11 experience, as did the work done on libinput to improve touchscreens and pen tablets. It worked so well that many people wonder, why not just keep doing X11 then?

I just think there's no future in it. It's not that it's physically impossible; obviously, Microsoft is able to make all of its old systems cope reasonably well with a modern desktop compositing system, including complex things like DPI virtualization. It's not literally impossible for X11 servers to fix these problems. But the thing about a lot of those improvements, including the improvements to DRM, KMS and libinput, were investments in the future and backporting them to X.org helped improve them quite a lot. Trying to retrofit something like DPI virtualization or color management into X11 would be a massive unthinkable time investment that would mostly be in service of a protocol and codebase that already felt dated by the late 90s. It took years just to make a good color management protocol for Wayland where it's actually something that slots well into the design! And it's not just "ha ha wayland developers dumb", the thread is huge and sprawling with legitimate concerns mostly surrounding how to do color management right. Spending that time on X.org just feels like it's a waste. If you try to clean up the unbelievably vast amounts of legacy cruft, you will lose compatibility with a lot of older software, somewhat defeating the point of keeping X11 around. If you try to work around it, you will surely wind up spending an awful lot of time trying to not break things that haven't been updated since George Bush was in office. (In some cases, Senior.)

Maybe I can't make the case to everyone for why X11 is such a bad investment. I know a lot of people have a negative knee-jerk reaction to the idea that all legacy code must be thrown away and rewritten in Rust and other trendy things, and even something as old and weird as the X.org codebase just isn't enough to convince them that this is not one of those cases. Even in that case, I don't think the case for Wayland is really as weak as it seems based on its flaws. To be fair, I think most people complaining about Wayland are fundamentally right, but often frame things in a fundamentally poor way. Very few of the limitations of Wayland compositors that exist today are inherent, and many of them are getting resolved on a month-to-month basis. When developers claim "this can never be done because I don't have something like SetWindowPos", that's just annoying. Any feature can be done without direct access to these sorts of facilities, and I think that Wayland pushing window management tasks back to the window manager is something that will age very well even if it is painful at first.

I will definitely acknowledge is that for application developers, its annoying that you can do one thing on Windows, macOS, X11, BeOS, basically every other desktop system on Earth, and then you have to special-case that thing on Wayland. That's definitely going to be painful for developers who want to write software that runs directly atop Wayland. However: Open source software does not have the benefit of being able to move fast and jump on emerging trends as they start to become popular. I think that the developers of Wayland saw all the way back in 2008 that the longer term future was going to be different when it comes to window management. Obviously, they saw that desktop compositing would eventually be everything. But I think they also saw that for both privacy and security reasons and for the benefit of better window management, giving direct access to position windows is an artifact of many features that really ought to be provided by the window manager. If they wanted Linux to have a desktop system that felt "modern" in 2030, they needed to start making the moves towards that in 2008, because it wouldn't only take an enormous amount of time to make Wayland happen, but for the ecosystem to adjust to it as well. I think they also reasoned, correctly, that the vast majority of developers would not be using Wayland directly, but would be using GTK, Qt, SDL, etc. which I think is still true.

Also true is that some software and definitely some UI toolkits will never fully be able to cope with the windowing model that Wayland presents them, but this isn't actually the dealbreaker everyone seems to think it is.

First of all, I believe XWayland is here to stay for a long time. We're really not all that close to even being able to remove XWayland and I don't anyone really wants to soon. If developers are unable or unwilling to work to make their apps work on Wayland, that is fine. X11 is still here. Some developers will bravely start huge efforts and it will wind up benefiting the whole ecosystem by possibly introducing new protocols, providing tons of experience reports, and probably making compositors more robust all at the same time. A good example is Godot. Other software is just waiting for now and forcing XWayland; an example of that is Krita. A lot of eager enthusiasts may be bugging developers to start getting things going, but I think by and large there's no real reason to rush. For most users, XWayland is good enough.

Secondly though, I think that even old toolkits that rely on concepts like the ability to directly introspect and modify window geometry can be made to roughly work. Obviously, Qt 5+ do generally work on Wayland, with some limitations. (Well enough that most apps don't really have to change anything.) The winewayland.drv in Wayland makes Wine generally work on Wayland, with some quirks (probably a lot less than you're imagining, especially as of late.) While you obviously can't do everything the same, it is possible to virtualize old APIs and use workarounds. I don't think all of the old apps are forever doomed to XWayland as it may seem today.

Will the Wayland desktop be "ready" in 5 years? I think it will be "ready" in closer to 1-2 years, at least if the current rate of progress keeps up. Rather than being worried about the Wayland desktop being ready from the compositor/protocol/application end, I'm more concerned about the continuing progress on the NVIDIA end, which has been promising from multiple angles but still a bit slow moving.