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.
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.