displays: Wayland
Turns out that X no longer exclusively marks the spot. Jonni Bidwell goes treasure-hunting in Wayland and finds compositors aplenty.
Prepare for a bumpy ride as Jonni Bidwell engages the next-gen display protocol and blasts us all into the future and the promised world of a secured display.
Wayland, apart from being a small town in New England, is a next-gen display protocol. It will eventually replace the venerable X server, which has been at the heart of *nix graphics since way back in the 1980s.
You may have heard about Wayland already, because there’s roughly equal measures of excitement and consternation surrounding it. Ubuntu 17.10 shipped with Wayland as the default graphical session on hardware that supported it (which at the time was almost everything except Nvidia devices using its proprietary drivers). Ubuntu 18.04 also ships with a Wayland session, but because it’s an LTS release and users are still reporting Wayland issues, this is no longer the default. Fedora, being an adventurous sort of distro, has used Wayland by default since version 25, which was released in November 2016.
It’s common for critics in the Linux sphere to decry new technologies “not ready for prime time”, and Wayland is no exception to these scurrilous libels. But Wayland itself is a mature technology. It’s been nigh on ten years since its initial release, and it’s already being used in embedded hardware (see our interview with Igalia’s Juan José Sanchez in LXF235). The main reason why we’re not all using it already is because many X applications still need to be rewritten to support it.
Let’s talk about X, baby
The Linux display stack is a complicated beast. Actually it’s a whole stack of complicated beasts and we won’t attempt to explain it here. One of many good reasons for starting over is that the X.org server (which you’ll find somewhere in the middle of this beastly stack) itself is such a tangled mess of code that it’s very difficult for new developers to understand it.
In order to implement the X protocol completely, an X server needs to have all kinds of functionality: memory management, graphics primitives that are more inline with drawing on a plotter than rendering on screen, support for old style fonts… the list goes on. This made sense back in the day, but now much of this functionality is redundant. The kernel handles all memory management and display mode setting and we have a battery of libraries (cairo, pixman, freetype, fontconfig, pango and so on) that handle text and graphics primitives in a manner much more suited to how applications use them.
X has been extended to cope with today’s graphics needs, most notably by the XrandR (for dynamic resolution changes) and Xrender (for image compositing) extensions. In theory, it could be extended further, but according to the Wayland FAQ ( https://wayland.freedesktop.org/faq.html), a new approach is better.
The current implementation of the X server used on Linux, X.org (which replaced X11R6 in 2004), finally saw a new release, 1.20, in May 2018. A great deal of the work involved with that release was concerned with the XWayland compatibility layer – a rootless X server that proxies its output via Wayland. This enables legacy X applications to run seamlessly on Wayland.
At first glance it seems odd, or inefficient, to re-implement what we’re trying to replace here, but XWayland is an optional code path; it only runs when it’s called upon. So we’re not necessarily running two display systems all the time. And as we’ll see, it’s quite a
challenge to have a general-purpose desktop that runs only X applications (or “legacy clients” as they’re called in Wayland parlance). Modern toolkits like GTK and Qt enable you to specify a rendering backend at launch time, so misbehaving applications can be forced to use Xwayland or Wayland as appropriate. For example, with GTK we can use GDK_BACKEND=x11 firefox to run Firefox with Xwayland, and with Qt we can use e.g. kate
-platform wayland to start Kate under Wayland. There are important security benefits to using Wayland. X was born in a different age, where no one thought applications needed to be isolated from one another. Back then it wasn’t seen as a problem to enable one application to access another’s input events (keystrokes and mouseclicks) or even to send false events to it. Unfortunately this means malevolent programs can do things like keylogging or keystroke injection. It’s also possible for one application to access another’s output (what it draws in its windows), or even alter the properties of its window.
With Wayland, applications are much more isolated. For example, keyboard events are only sent to the active window and one application can’t access the contents of others’ windows. This is obviously A Good Thing, but it does make life difficult when it comes to things like screenshots or sharing. In fact making standard desktop components suddenly becomes very tricky under these restrictions.
For reference only
A traditional Linux desktop environment has a separate compositor and window manager running on top of the X.org server. Under Wayland, these components are all integrated, which makes for a simpler architecture. Wayland itself is just a protocol, though. For it to be useful it needs a concrete implementation of those components (collectively called a Wayland compositor).
A reference Wayland compositor is available, and is named Weston (also a New England town). Weston is the best place to start our Wayland experimentations ( Weston the compositor we mean, geographically you can be anywhere as long as its near a Linux distribution). Even if your distro comes with a Wayland session, you’ll still probably be missing Weston. Install it with the following: $ sudo apt install weston or something like that on other distributions. Weston can run from within an X session, and running it this way is probably least likely to result in crashing or burning.
Fire up a terminal and run weston . You’ll be greeted with a stylish grey tessellated background (perhaps a nod to the old grey mesh pattern that once was the default X background) with a menubar along the top and, well, not much else really. Weston isn’t all a barren wasteland, though. You can launch a terminal using the button in the top-left corner, and from here there are a variety of utilities you can play with. On Ubuntu at least, these are hidden away in Weston’s install directory. Run $ cd /usr/lib/weston $ ./weston-smoke to witness our favourite demo. Move the mouse cursor across the dimmed area, and be amazed. Click inside the terminal and hit Ctrl+C when you’re done being amazed. For further amusement, run ./weston-flower & three or four times. Then drag around the resulting shapes to your heart’s content. You’ll find a number of other little demos by typing ./weston- and hitting Tab. We won’t spoil the surprise or bore you by going through them one by one.
As you may imagine, running a Wayland compositor inside an X (or even a Wayland) session isn’t exactly the future of the Linux desktop, so for our next trick let’s try and run it natively. Log out of your current desktop session, and switch to a TTY with Ctrl+Alt+F2 . Log in old style, and if you really want to be minimal about this stop the display manager service with, for example,
sudo systemctl stop gdm (change the service name appropriately – KDE Plasma-based distros probably use the sddm display manager). Now run weston and see if things go wrong this time.
Your distro probably added a Weston session to your display manager, so stopping it isn’t strictly necessary. Anyway, without further configuration, Weston will start with a low resolution, but this and a variety of other things can be changed through the ~/.config/weston.ini