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.
Yes, I know Wayland has made some controversial design choices. The fact is, Wayland is the only viable X11 successor, which will hopefully bring more security and stability to the Linux desktop. Regardless of how it pans out, there’s nothing like a bit of competition to drive innovation. I won’t discuss any more politics in this post. Also a disclaimer: I’m no systems programming expert (though I aspire to be), neither am I an expert in X11, Wayland, or their associated protocols or codebases. This post merely draws on my experiences as an end user that enjoys a highly customised workflow. Wayland has been the talk of the town in the Linux world for quite a while now, but it seems a lot of important pieces of a modern desktop Linux distribution simply aren’t ready for it.
For those who haven’t encountered it before, xlogo is a trivial X11 application that pops up a window showing the X Window System logo. It’s close to being the X equivalent of a ‘hello, world’ program, which makes it a good lightweight initial test case. Whenever I need to do a quick check of my X11 connectivity (which in my case usually means I’m checking that SSH X forwarding is basically alive), xlogo is a good choice of program to run: it won’t spend ages setting itself up, and unlike text-only alternatives like xdpyinfo, it’ll pop up a window on the target display, which makes it easy to check that my connection has gone to the right display. But that’s not all xlogo is good for. There are several other things I use it for. I remember xlogo from the very first few times I used Linux – somewhere in 2002 or 2003. Together with stuff like xeyes, it was a fun little toy to experiment with after installing Linux for the first time. I had no idea it could actually be useful.
A small collection of cool Unix tools for the X Window System. For cool terminal tools, see Kristof Kovacs’ list. All applications have been tested on FreeBSD but should run on other Unix-like operating systems as well.
Arcan is a display server++ project that has been mentioned on OSNews a few times before. Arcan's developers recently posted an
in-depth comparison of Arcan to Xorg - claiming to soon be not only at feature parity but beyond it.
It is worthwhile to stress that this project in no way attempts to 'replace' Xorg in the sense that you can expect to transfer your individual workflow and mental model of how system graphics works without any kind of friction or effort. That said, it has also been an unspoken goal to make sure that everything that can be done in an Xorg environment should be possible here - in general there is nothing wrong with the feature set in X (though a bit limited), it is the nitty gritty details of how these features work, are implemented and interact that has not really kept up with the times or been modelled in a coherent way. Thus, it is a decent requirement specification to start with - just be careful with the implementation and much more can be had to a fraction of the code size.
A fascinating read if you are familiar with some of the technical difficulties here.
However, I still field plenty of questions from lots of people about this, and a lot of the time, it's extremely simple stuff: "What is X?" "How does it interact with my graphics card and mouse/keyboard?" "What do apps use X for?" "What is Wayland, and how does it fit into the picture?" "What problems did X have that made us want to write new display server technologies?"
These sort of questions were what inspired me to write "The Linux Graphics Stack" in the first place, but there's really never been a comprehensive, historical writeup of our display server technologies in general. So, I chose to spend my free time at Red Hat writing it.
A very fun look at what X actually is - including embedded X server sessions running in your browser using HTML5 canvas. Fancy.
CDE 2.2.1 has been released on March 1. The release includes various bugfixes, a NetBSD port and improvement for UTF-8 locales with a new Greek UTF-8 translation.
Aside from the really cool stuff regarding X11, I'm absolutely fascinated by the user interface of this exotic piece of hardware. It's quite utilitarian, but still has an interesting sense of beauty and focus. I'd love to play with this (even though I have no idea what this equipment actually does).
Intel on Ubuntu's XMir
We do not condone or support Canonical in the course of action they have chosen, and will not carry XMir patches upstream.
Ubuntu has to do virtually all its work on Xmir drivers by itself. No one else supports it.
"Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues
in the way various X client libraries handle the responses they receive from servers, and has worked with X.Org's security team to analyze, confirm, and fix these issues."
Any modern operating system consists of layers upon layers of systems, services, and libraries. Increasingly, no one can possibly have full understanding of all the layers of the cake. Here's RedHat developer Peter Hutterer's description of what it takes to move the cursor on your screen
. Interesting to get back to the basics, and a good reminder of how complicated this stuff really is.
Lead developer for Compiz, Sam Spilsbury, says he sees little need to develop Compiz for Wayland
due to the increasing fragmentation of the Linux ecosystem. Spilsbury writes "What does compiz actually provide to users of these systems? None of this functionality that user wants really depends on our compositing engine. There's nothing so special about our compositing engine that gives it a reason to exist This is the real practical toll of fragmentation amongst the Linux ecosystem. It's not just that there are multiple implementations of the wheel. There are multiple implementations of entire cars which do almost the same thing, but a little different from everyone else. Some say this is the free software's greatest strength. Now that I know the personal and technical toll of fragmentation, I see it as its greatest weakness."
"For two decades, X has been the foundation for Linux graphics. Ubuntu's decision late in 2010 to switch to Wayland shakes things up all the way to those roots
. Just over a month ago, the official 1.0.0 release of Wayland appeared, as well as its associated Weston project. How will these milestones affect working GUI programmers? What will happen to all the existing toolkits - Qt, wxWindows, Tk, and others - on which so many graphical applications already depend?"