Does Wayland really break everything?

I’ve written some other posts 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!” 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 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!

115 thoughts on “Does Wayland really break everything?

  1. 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.

    Liked by 1 person

  2. 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).

    Like

    1. 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.

      Liked by 1 person

    2. 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.

      Like

  3. “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…

    Like

Leave a comment