Wayland Archive
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.
While many Linux enthusiasts like to cite Linux’s stellar support for older hardware platforms, in reality that isn’t always the case. For instance with many old X.Org user-space mode-setting drivers for powering old graphics cards at least for display purposes, they can no longer even build with with modern toolchains/software components. Given the lack of bug reports around such issues, there are very likely few users trying some of these vintage hardware combinations. Longtime X.Org developer Alan Coopersmith of Oracle recently looked at going through all of the available X.Org drivers that aren’t in an archived state and seeing how they fare — with a goal of at least setting them up for simple continuous integration (CI) builds on GitLab. This is the inevitable result of hardware that was often already obscure and rare when it was new – let alone now, decades later. All we can hope for is a few people still carrying this hardware to donate either time or hardware to aid in keeping these drivers building and running.
I’ve spent the last couple weeks writing a window system for the VS100. I stole a fair amount of code from W, surrounded it with an asynchronous rather than a synchronous interface, and called it X. Overall performance appears to be about twice that of W. The code seems fairly solid at this point, although there are still some deficiencies to be fixed up. The original mailing list announcement of the Linux kernel gets regurgitated quite often, but I had never seen the original announcement for X. Fascinating.
A desktop environment I had never heard of until now has seen its first new release in 611 days – always awesome to read about unknown projects like this, so here we go. Anyway onto the point, yes the project is still alive and there’s been some updates. This release encompasses two main things. First is a collection of minor fixes that have gone into master since 1.6.0 came out, along with some translation updates. This includes two small additional binaries for use by the desktop. Second is that the downstream theme work that we did for Project Trident is now in Lumina as the default theme. Lumina is an open source, lightweight desktop environment written from scratch in C++/Qt5. The related Project Trident is a desktop Linux distribution based on Void Linux – excellent taste, just excellent – that uses Lumina as its desktop environment.
The NVIDIA-led work to allow XWayland OpenGL and Vulkan acceleration with their proprietary driver has just been merged into X.Org Server Git. The XWayland changes needed to allow the NVIDIA proprietary driver to work in an accelerated manner have landed in X.Org Server 1.21 Git. The main change is xwayland: implement pixmap_from_buffers for the eglstream backend that was merged just a few minutes ago. NVIDIA is a big blocker for Wayland, so any steps forward are good steps – even if it takes a while before this code ends up on our desktops.
This article is a guide for achieving a full-as-possible Wayland setup on Arch Linux. This guide does exactly what it says – it helps you set up a complete Arch Linux installation that is as Wayland as possible.
The focus of this update is to support a number of new features that are useful for applications and games, and which have also been considered potential integration pain points for the Wayland driver. These are copy/paste, drag-and-drop and support for changing the display mode. Getting Wine properly supported on Wayland is a hugely important step in the move to Wayland, because thanks to Wine/Proton, gaming on Linux is massively viable. Having to use XWayland for games is not something I’m looking forward to.
Here we go. Wayland is not ready as a 1:1 compatible Xorg replacement just yet, and maybe never will. Hence, if you are interested in existing applications to “just work” without the need for adjustments, then you may be better of not using Wayland at this point. Wayland solves no issues I have but breaks almost everything I need. And usually it stays broken, because the Wayland folks only seem to care about Gnome, and alienating everyone else in the process. DO NOT INSTALL WAYLAND! Let Wayland not destroy everything and then have other people fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone! I’ll save you a read and summarise the ‘article’ so you can do something more productive, like I don’t know, cleaning your floors with a toothpick or something: “my tools and components written specifically for X and its APIs do not work under Wayland, therefore Wayland is garbage and shit”. Wayland is not X.org. Let me repeat that. Wayland is not X.org. If you need the functionality that X.org delivers, then you shouldn’t be using Wayland. This is like buying a Mac and complaining your Windows applications don’t work.
We talked about the state of X.org earlier this week, and the wider discussion was picked up by Adam Jackson, who works at Red Hat as the X.Org Server release manager, and has been heavily involved with X development for many years. There’s been some recent discussion about whether the X server is abandonware. As the person arguably most responsible for its care and feeding over the last 15 years or so, I feel like I have something to say about that. So, is Xorg abandoned? To the extent that that means using it to actually control the display, and not just keep X apps running, I’d say yes. But xserver is more than xfree86. Xwayland, Xwin, Xephyr, Xvnc, Xvfb: these are projects with real value that we should not give up. A better way to say it is that we can finally abandon xfree86. Seems like a fair and honest assessment.
Besides the likes of Red Hat, Intel has been the only other major organization in recent time willing to devote resources to areas like X.Org release management, but even while they let go some of their Wayland folks years ago, they seem uninterested in devoting much in the way of the X.Org Server advancements as we approach 2021. With Ubuntu 21.04 also possibly defaulting to Wayland for its GNOME session, the KDE Wayland support getting squared away, and other advancements continuing, X.Org Server 1.21 may very well prove to be an elusive release. The transition to Wayland is taking far longer than it should, and a lot of important software simply isn’t ready yet. KDE is still hard at work, and my desktop environment of choice – Cinnamon – has zero support in the works for Wayland. Don’t get me wrong – I’m excited for Wayland – but it feels like we’re counting down by continually multiplying by 0.5 – no matter how many times you multiply, you never quite reach zero.
Today, we are excited to announce the 0.14 release of xrdesktop, the Open Source project which enables interaction with traditional desktop environments, such as GNOME and KDE, in VR. xrdesktop makes window managers aware of VR and is able to use VR runtimes to render desktop windows in 3D space, with the ability of manipulating them with VR controllers and generating mouse and keyboard input from VR. Sponsored by Valve, this latest release brings the largest amount of changes yet, with many new features and architectural improvements. Most importantly, the most exciting improvement is that xrdesktop is now able to run on XR runtimes providing the OpenXR API, which enables running xrdesktop on a full Open Source stack with Monado. One day I’ll get a VR headset, but for now, I feel like the cost of a set that isn’t garbage is simply too high, and whenever I see someone playing a game in VR, it looks clunky and cumbersome both inside the game and outside in the real world. This technology has a while to go.
NsCDE is a retro but powerful (kind of) UNIX desktop environment which resembles CDE’s look and (partially feel), but with a more powerful and flexible beneath-the-surface framework, more suited for 21st century UNIX-like and Linux systems and user requirements than original CDE. NsCDE can be considered as something between a heavyweight FVWM theme on steroids, combined with a couple of other free software components and custom FVWM applications and heavy configurations. NsCDE can be considered as lightweight hybrid desktop environment. Be still, my beating heart.
