Wayland and X.org are both part of freedesktop. Whatever maintenance is still happening on X.org is mostly being done by people who primarily work on Wayland. There isn’t some kind of holy war going on between The Wayland Developers who want to kill X.org, and The X.org Developers who believe it is great and want to keep it. They’re nearly all the same people, and they all want X.org to die. AFAIK there isn’t anybody who is actually clamoring to *do the work of maintaining X.org upstream*. There are people who don’t want it to die because Wayland doesn’t yet have the features they need or the NVIDIA proprietary driver doesn’t work well on Wayland or whatever, but AFAIK, none of those people is actually volunteering to maintain X.org long-term. ↫ Adam Williamson There’s really no clearer summary of the current state of affairs than this.
One of the somewhat odd things about my old fashioned X Window System environment is that when I ‘iconify’ or ‘minimize’ a window, it (mostly) winds up as an actual icon on my root window (what in some environments would be called the desktop), in contrast to the alternate approach where the minimized window is represented in some sort of taskbar. I have strong opinions about where some of these icons should go, and some tools to automatically arrange this for various windows, including the GNU Emacs windows I (now) use for reading email. ↫ Chris Siebenmann Iconification should be possible in any modern desktop environment, and it’s sad that this paradigm has pretty much entirely vanished. I would love for iconified windows to be treated essentially the same way as files, so you can move them around, drop them inside directories, and even move them from one computer to another (assuming they have the application in question installed). If I’m working on a project, and I have a bunch of LibreOffice documents, spreadsheets, browser tabs, notes in a text editor, some images open, and so on, I should be able to iconify them all, keep them in the project’s directory, and de-iconify them as if nothing had ever happened. Right now, you have to use files and application states for that, which is cumbersome and annoying. Sadly, advanced window management is dying. Shame.
While there are a lot of Wayland compositors out there that aren’t too different from each other in terms of features, one of the more unique ones is Greenfield. The Greenfield Wayland compositor has been out there for a few years now as an in-browser HTML5-based solution that is continuing to prove itself capable and even fast enough for handling Linux gaming. ↫ Michael Larabel A rather genius idea for a Wayland compositor.
Niri is a scrollable, tiling window manager for Wayland. What does it mean for a tiling window manager to be scrollable? Windows are arranged in columns on an infinite strip going to the right. Opening a new window never causes existing windows to resize. Every monitor has its own separate window strip. Windows can never “overflow” onto an adjacent monitor. Workspaces are dynamic and arranged vertically. Every monitor has an independent set of workspaces, and there’s always one empty workspace present all the way down. ↫ Niri’s GitHub page Definitely an intriguing idea.
The Wayland ecosystem had a phenomenal year from much better NVIDIA proprietary driver support, Firefox ending out the year shipping with Wayland support enabled by default, KDE Plasma 6.0 will default to Wayland following many improvements on the KDE side, the Wine Wayland driver upstreamed in its initial form, XWayland continuing to be enhanced, and a lot of other software from desktop environments to apps continuing to embrace Wayland. ↫ Michael Larabel at Phoronix This train ain’t stopping. Dare I say 2024 will be the year of Wayland on the desktop?
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. ↫ Nate Graham at Pointie Stick Will all the people who both can and want to work on X.org please raise their hands? Oh, no hands? What a shame.
You may have seen the news that Red Hat Enterprise Linux 10 plans to remove Xorg. But Xwayland will stay around, and given the name overloading and them sharing a git repository there’s some confusion over what is Xorg. So here’s a very simple “picture”. ↫ Peter Hutterer A more useful visualisation than I expected.
While most X.Org Developers Conference talks are around graphics drivers / infrastructure work itself, one of the other interesting XDC 2023 talks was Alexandros Frantzis around the ongoing work of providing a native Wine Wayland driver so that this open-source project can interact directly with Wayland and so Windows games/applications running under Linux will no longer need to go through XWayland. The entire presentation is available on YouTube.
Wayland is all the rage those days. Distributions left and right switch to it, many readers of my previous article on writing a X11 GUI from scratch in x86_64 assembly asked for a follow-up article about Wayland, and I now run Waland on my desktop. So here we go, let’s write a (very simple) GUI program with Wayland, without any libraries, this time in C. In case you’re bored this weekend.
Cairo 1.18 was released today as the first major stable release to this 2D graphics library in five years. This vector-based graphics library is widely-used for a variety of purposes from GNOME’s GTK toolkit to other apps making use of Cairo for targeting different back-ends from PDFs to OpenGL contexts. Mozilla Firefox, WebKit, Mono, and many other open-source projects are notable users of Cairo. Cairo is something most end users don’t really have to think about or worry too much about, but it’s a crucial part of the open source operating system world. The most interesting change in 1.18 is that it drops support for a variety of old back-ends, most notably Qt 4, BeOS, and OS/2.
The Wayland Color Management protocol has been years in the making and is needed for a client to specify the color space and HDR metadata of a surface. This color management protocol is ultimately needed for getting high dynamic range (HDR) support working out well within Wayland environments. This week an initial merge request was opened for implementing the draft color management protocol with the Weston reference compositor. This is an important part of getting HDR working properly on Wayland, and thus making sure the Linux desktop gets full, proper HDR suport. On a related note, the Wayland Wine driver has also seen some progress, adding basic window management capabilities.
KDE’s Nate Graham talks about Wayland, and sums up both its history, current status, and the future. Wayland. It comes up a lot: “Bug X fixed in the Plasma Wayland session.” “The Plasma Wayland session has now gained support for feature Y.” And it’s in the news quite a bit lately with the announcement that Fedora KDE is proposing to drop the Plasma X11 session for version 40 and only ship the Plasma Wayland session. I’ve read a lot of nervousness and fear about it lately. So today, let’s talk about it! Wayland is a needlessly divisive topic, mostly because the people who want to stick to X.org are not the same people with the skills required to actually maintain, let alone improve, X.org. Wayland should not be a divisive topic because there’s really nowhere else to go – it’s the current and future of the Linux desktop, and as time goes on, the cracks in X.org will start to grow wider and longer. In essence, Xorg became too large, too complicated, and too fragile to touch without risking breaking the entire Linux ecosystem. It’s stable today because it’s been essentially frozen for years. But that stability has come hand-in-hand with stagnation. As we all know in the tech world, projects that can’t adapt die. Projects that depend on them then die as well. My biggest – and basically only – issue with Wayland is that it’s very Linux-focused for now, leaving especially the various BSDs in a bit of a rough situation. There’s work being done on Wayland for BSD, but I fear it’s going to take them quite a bit of time to catch up, and in the meantime, they might suffer from a lack of development and big fixing in their graphics stack.
Adding screen savers to Wayland is not simply a matter of “port the XScreenSaver daemon”, because under the Wayland model, screen blanking and locking should not be a third-party user-space app; much of the logic must be embedded into the display manager itself. This is a good thing! It is a better model than what we have under X11. But that means that accomplishing that task means not just writing code, but engaging with whatever passes for a standards body or design committee in the Wayland world, and that is… how shall I put this… not something that I personally feel highly motivated to do. However, as I am the world’s foremost expert on screen savers on Unix-like operating systems, here are a few simple admonitions for young and old. Jamie Zawinski imparts his wisdom.
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.
X11 is, to put it simply, not at all fit for any modern system. Full stop. Everything to make it work on modern systems are just hacks. Don’t even try to get away with “well, it just works for me” or “but Wayland no worky”. Unless your workflow (and hardware) comes from 20+ years ago, you have almost no reason to stick with Xorg, especially as it continues to get worse and worse when the user experience relies on newer and newer features. Almost everything that didn’t work even two months ago works now, and tons of progress is being made so it works for almost everyone – yes, even you, NVIDIA users. With that being said, let’s get on with it. Expect me to be blunt, and wordy. I’ll also be a bit technical. Probably going to devolve into some crying after seeing just how horrible X is. Sticking to legacy, unmaintained software like X.org because it contains some niche feature not yet working in a Wayland environment is entirely valid. Claiming Wayland is crap and X.org is better? That’s utter nonsense, and this article explains in great detail why that is so. Wayland is better. No ifs and buts about it.
In our State of the Budgie blog post in May of last year, we emphasized that Budgie 11 would be Wayland-first, with initial expectations being that we would support an X11 fallback mode, as well as mentioning that “it is not entirely out of the realm of possibility to have a Budgie 10 under Wayland”. Since that blog post, several key developments have occurred in the Wayland ecosystem. This detailed article about the future of Wayland support in Budgie is a great read. If you’re interested in the kinds of considerations and decisions that go into maintaining a Linux desktop environment in 2023.
Wayland is an interesting beast. X11, for all its faults, does a lot for the desktop environment. If you’re stretched for time, you could – in theory – just slap a panel onto the default X11 window manager and call it a day. The modern landscape of desktop environments built on top of X11 exists because developers have gotten really good at eschewing X11’s built-in crusty junk for their own new and shiny junk, so that things work as you’d expect them to. For the most part, this kinda works – with enough hacks, you can get things like variable refresh rate, fractional scaling, et cetera. The problem here is that X11 definitely was not built for those things. Variable refresh rate works, but only if you’re using a single monitor, and mixed refresh rate monitors in a single X session don’t work at all outside of the hardware cursor. Fractional scaling is a hack. Compositing in general is optional and is sort of just stapled onto the existing architecture. X11 does do what it needs to do, which is display windows, but it’s kinda garbo when you need it to do anything more advanced. Wayland is what happens when issues with the dominant windowing protocol have been festering for decades. It throws away everything and establishes a core set of standards that must be adhered to, along with a (very large) set of extensions that can be optionally implemented. The website https://wayland.app/ shows all the protocols worth knowing, and a lot more on top of that. It’s kinda like Vulkan, in a sense: the core has the basics, and everything else is extensions that can be queried for by clients. Wayland is such a massive improvement over X11 it absolutely boggles the mind that people try to claim otherwise. I’m glad we’re finally at a point where Wayland has clearly won, and developers are finally free to focus their efforts on the clearly superior choice, instead of wasting more time trying to hack X11 into the 21st century.
One of my favourite software projects got a brand new release – the Not so Common Desktop Environment (NsCDE) 2.3 has been released. NsCDE brings the look, feel, and behaviour of CDE to the modern Linux desktop through a combination of themes, scripts, FVWM customisations, and a lot more. This new release brings the usual bugfixes, but also new features – like Qt6 integration, CSS updates for newer releases of Firefox and Thunderbird, and more.
Reading how copy-paste works from the Wayland specification is non-trivial unless you understand a lot of how desktop computing works and Wayland internal. It took me quite a while to figure it all out, though once you get there, it seems quite obvious. Here’s my attempt at explaining how it works for mere mortals. One of those things you do countless times every day, but don’t really know how it works.
All in all, I’m very impressed with the work the wayland community has done since I last did a serious look at the state of things. I’m still waiting for a stacking window manager that scratches the same itch for me that icewm does, but I’m following labwc with great interest. At this point though, I’ve established that I can live my life on wayland, and for the time being I am. Not everyone can yet though, and there’s still work to be done. Part of why I’m feeling the urge to transition to wayland is performance benefits, but the other part is so that I’ll be able to help solve the unsolved problems to make it viable for more people. I don’t think X is ever going to die. Even if it fades away on Linux, there’s a lot of old video hardware that will probably only ever be well supported with real Xorg, on Linux and other OSes such as NetBSD. That stuff is already seeing support dropped in more recent versions of Xorg, and preservationists will need to do digging to find versions that still take advantage of everything the hardware has to offer. But, I understand now why the wayland folks have been talking so highly of it, and how drastically it simplifies the userland stack, and I’m no longer concerned that I’ll wake up to find my netbook has become unusable for modern software. I’ve been on Wayland on both my laptop and workstation for a long time now, and there’s no way I’m ever going back with just how much better it performs than X.org. Only my main PC (used mostly for gaming) is still on X.org (Linux Mint), but that’s out of a combination of NVIDIA hardware and my satisfaction with Mint. I agree with the author that X.org won’t die, but the arrow of time is pointing in a very clear direction.