Wayland Archive

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.

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.

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.

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.

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.

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.

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.