Today I read Wayland breaks your bad software, which is in large part an inventory of how Wayland is technically superior to X. I don’t particularly disagree with Wayland’s general technical merits and improvements, but at this point I think that they are mostly irrelevant. As such, I don’t think that talking about them will do much to shift more people to Wayland.
(Of course, people have other reasons to talk about Wayland’s technical merits. But a certain amount of this sort of writing seems to be aimed at persuading people to switch.)
I say that the technical merits are irrelevant because I don’t believe that they’re a major factor any more in most people moving or not moving to Wayland.
There’s always multiple angles to things like this, and I would prefer to highlight them when I can.
The upgrades that Wayland brings to the user are needed in this decade (e.g. smoothness, screen sizing etc). Wayland is a needed step. The problem is that it’s already old school architecture. Basically, Wayland was developed as an architecture in 2008, and that’s epochs away in terms of how modern compositors work today. I’d say, the most progressive and modern architecture when it comes to compositors is Android’s. It surpasses everything else out there, any other OS, mobile or desktop. That is the model that needed to be literally copied over.
Are you sure that Android is suitable for desktop use? I am far from knowledgable about compositors, etc but Android would seem to be aimed at a single physical screen with all apps running fullscreen on that device simplifying the requirements immensely. No multiscreen, no window decorations and no window-forwarding. Would it be suitable for these tasks?
These are easily added. The magic of Android’s compositor is in its overall speed at low level. The guy who wrote it, Romain Guy, is quite a genius.
But, is it the architecture or the implementation?
Well, yes — but that’s not the people that should be making the change!
Switching most of the user base over to Wayland is IMO the task of two different (although often imbricated) groups of people:
• Software developers (of GUI-enabled desktops and applications)
• Linux distribution developers and builders
When enough software developers understand the real technical reasons (that are important to them, or that they are convinced to push the users to), Wayland support for users becomes feasible. This means — why didn’t users migrate over to Wayland 10 years ago, when Weston became available? Because they’d be stuck in a better environment, but without application support. Of course, it was great that the major graphical toolkits’ developers became convinced of porting their code to Wayland. And, yes, a decade ago there was the discussion of whether Wayland or Mir (or something else entirely) would get the needed traction (or whether X.org would wake from its slumber and get cleaned up as it did during the XFree→X.org shakedown).
Around five years after, some distribution developers started adopting Wayland instead of X.org by default, at least in GNOME-land. I know I hated it when Debian did so (I think I suffered it was early in the pandemic, when I upgraded my wife’s computer). We used to have different incarnations of vnc installed in all of our home computers, and suddenly it stopped working. I moved them all back to X.org.
Slowly and steadily, all major pain points are being taken care of. Some desktop environments, as the article points out, still don’t offer native Wayland support — but I predict they will cede and jump over within the next three years.
As someone who has written software that directly uses X11 and Wayland, I can say that I really don’t like the Wayland software stack as a target. X11 really isn’t as arcane as people seem to make it out to be, and I found it a lot easier to do things like manage the event queue, get an OpenGL context (including OpenGL 3.1+ support), request different pixel formats, etc. In particular I am unmoved by the event API which seems to be trying very hard to be similar to the Android stack, which is pretty annoying to use.
Sometimes something simpler is just nicer to deal with, even if it it’s not shiny and new.
I don’t support Wayland in my software anymore because 1. many of my machines just don’t have it, they are BSD variants, but all my machines can run X11, and 2. it’s just not as nice to program for.
*nod* “X.org is such a mature codebase that I can run it for months without a crash taking down my session” isn’t exactly a technical merit of the protocols, regardless of whether it’s being surfaced by Wayland compositors moving the crash/bug-prone compositor into the same process.
If KDE weren’t making decent progress toward compositor crash recovery and LTS releases of distros that offer X sessions didn’t exist, and I weren’t already well on my way to jettisoning those foot-dragging GTK apps for unrelated reasons (UI design ones), I’d be looking into building a stack which runs something like Xpra on top of XWayland on top of a Wayland compositor existing purely for hardware support, and then connect all my apps to that over X11, to synthesize crash recovery without a single point of failure that could take down all my apps that sticking something like kwin_wayland’s X11 backend on top of that would be.
In the longer term, I’m hoping that Arcan will develop into something that is to Wayland compositors as AwesomeWM was to Mutter… something which supports the same applications, but which provides enough “this is UNIX and UNIX is a reprogrammable IDE like emacs is, so don’t try to swaddle the programmers”-ness to implement the compositor I want.
I certainly VERY MUCH appreciate the outlook and level of detail on Arcan’s blog.
(And I say this as someone who initially welcomed Wayland’s support for things like multi-monitor tearing prevention and/or VRR, and preventing applications from being able to permanently change the resolution by accident.)
I couldn’t have said it better.
For me personally, Wayland is just not there yet, not because it isn’t usable on Linux based distros (it is, as far as I can see) but because I have been increasingly moving to OpenBSD full time for my workstations. There is early work being done to port Wayland to OpenBSD but I’m not interested in it enough right now to comment further on that progress. This is because OpenBSD’s own fork of Xorg, called Xenocara, already addresses most (if not all?) of the shortcomings of Xorg, making Wayland irrelevant for probably any OpenBSD user who is not personally invested in bringing Wayland over.
Further, Wayland (like systemd) is a Linuxism; it was born on Linux, made specifically for Linux, by Linux enthusiasts who by and large either don’t care about other UNIX-likes or are actively hostile towards them. There’s absolutely nothing wrong with wanting a better display server and protocols for Linux, just as there’s nothing wrong with wanting a better init system for Linux. I just don’t see them having any success or relevance on the BSDs. And that’s fine.
Morgan,
Yeah, linux being dominant among alternative operating systems creates this dilemma for the rest. They want to do things their own unique way. They should; monocultures are dull. But without enough critical mass the industry targets the dominant platforms almost exclusively leaving the onus on the rest to be compatible with linuxisms including syscalls, quirks, subsystems, APIs, file formats and so on. Can BSD and other alternatives do these better than linux? Absolutely! But actually getting developers to target them first at the expensive of compatibility with linux is a non-starter for most authors. This has nothing to do with merit. For better or worse though, compatibility with linux is very important and alternative frameworks simply don’t get much attention.
The problem is running the Extra Mile.
I do understand when Wayland does not want to involve in Compositors or Java Swing Backends and Screensharing or Cast Applications. Its not their main responsibility.
However, my company has continuously to support our clients with Active Directory administration because we rely on AD for User/Group/Role management. I do hate this part of my job most. Still doing it every single time since the client would be stuck otherwise, with audit exceptions yielding in a bad reputation (because nobody ever cares about details).
So, as long as Wayland does not work with Java Swing (which is Oracle’s fault) and also does not provide a major advantage over X I will stay with X. Its just good enough.
My point is: If I want someone to use my software I must be ready to run the Extra Mile. If not then adoption will be slow unless I solve a real pressing issue, felt by the End-Users.
Most distros and users will move to Wayland when it works well with NVIDIA and KDE. The GNOME distros have pretty much moved already.
It’s abundantly clear that all of the non-Linux OSes need to get together & collectively maintain X11 before the Linux community’s Wayland push completely destroys X11’s future for the rest of us.