Swaying you to Wayland
The next-gen display protocol is ready for primetime! There, we said it send all your arguments to Jonni Bidwell…
What is the Wayland display manager, how does it work, and why should you care anyway? Jonni Bidwell explains all, or at least tries to.
The trusty X Windows display server has been around since the UNIXES of the ’80s. It came to Linux in the form of X386 (later Xfree86) in the ’90s, and the bona fide open source X.org fork took over in 2004. It’s been pushing pixels around Linux users’ screens ever since.
You no longer need to risk blowing up your monitor with manually specified display timings; in fact, you probably don’t need to configure it at all. It’s been extended beyond recognition to cope with new hardware and programming: XAA, GLX, Glamor, UXA and a slew of other obscure codenames and acronyms ensure that all your windows move around smoothly. Plus a bunch of its lowlevel functionality has been moved into the kernel, in the form of KMS.
The trouble is, X.org is still based on the ideas of 30 years ago; the display primitives it caters to are in many ways more relevant to plotters and printers than today’s displays and GPUS. Using it for modern graphics work (particularly gaming) is often described as trying to fit a square peg into a round hole. Besides technical shortcomings, it’s become a spaghetti mess of code over the course of its lengthy existence, to the point where any potential new developer would run away screaming, as if they’d stared into the face of Cthulhu (for president?–ed) itself.
Just as well there’s a replacement then. That is Wayland, a ground-up rethink of how displays and input devices should work. This new and shiny display server may not yet be the answer to all our problems, but it’s certainly worthy of your attention…
ayland has been in the works for ages. It was dreamed up in 2008 when developer Kristian Høgsberg was driving through the New England town of the same name. For many desktop users, it would come to sit, alongside systemd and Gnome 3, firmly in the box of ‘solutions looking for problems’. After all, we already had X – why not modernise and extend that, rather than adopt this thing which a) doesn’t work and b) even if it did it doesn’t do everything X.org (the current implementation of the X Window System standard set out in 1984) did? But sometimes less is more, and let’s see why.
One of X’s most powerful features was its network transparency. Its client-server architecture afforded the machine running the X server – the one connected to the monitor and input devices – the luxury of not caring whether X clients (applications) were run locally or from another machine. This is a handy feature – you haven’t lived if you’ve never run a graphical application over SSH – and enabled the thin client paradigm to flourish in the ’80s and ’90s.
Having all your applications installed on a single powerful machine served over the network to machines running little more than X saved businesses and colleges a lot of money, and also made UNIX skills more valuable. In a desktop context though, network transparency is rarely used, so all that model does is add complication. Remote rendering is tricky and today, for home use at least, it usually makes more sense to use a remote desktop program. Thus Wayland doesn’t support network transparency directly, though you can still run remote X applications via Xwayland.
Wayland is just a protocol, so we can’t apply the same notion of a display server to it. A graphical program wanting to render through Wayland does so by means of a display compositor. The reference compositor for Wayland is called Weston. Modern X desktops have display compositors too – they’re integrated into window managers now on fully featured desktops (Gnome has Mutter, KDE Plasma has Kwin), and on bare-bones window managers like i3 you can add a compositor like Compton.
These take lots of different rectangles and put them all in the right places in the right order to make a coherent desktop. Latterly they might also apply a bunch of shadow or transparency effects, and also manage timings to avoid screen tearing. Wayland hopes to be – and in fact already is – a slimmer, simpler way of pushing pixels. With Wayland, compositor, server and window manager are all more or less unified.
In our LXF243 interview with Collabora graphics veteran Daniel Stone, we learned that there are two approaches to implementing a Wayland compositor. Either you have a single unified environment that handles everything (menus, docks, desktop add-ons), or you do things piecewise: a small compositor program, with auxiliary utilities for handling everything else. We’ll look at both approaches here.
The latter approach is quite similar to the X way of doing things; even if you’re running a unified desktop environment like Gnome, you have an X instance running, a Mutter instance running on top of that, and all sorts of little things running alongside. Gnome has generally been considered the best place to try Wayland, having offered a full Wayland session since 2015. By only slightly tenuous extension, the best distro on which to try Wayland is Fedora, having long provided a solid, unadulterated Gnome experience. How convenient, then, that you’ll find the latest Fedora offering on the LXFDVD.
We won’t cover installing it (ever since that incident with the pitchfork-wielding mob – Ed) and for the most
Why Wayland (W)rocks “Wayland hopes to be – and in fact already is – a slimmer, simpler way of pushing pixels than X.”
part you can follow along using Gnome on Ubuntu (also on the disc), or any other distribution.
Fedora went all out and made the Wayland session the default back in Fedora 25. You can choose an X or Wayland session by clicking the small cog when you enter your password. If something goes wrong, you’ll either silently fall back to an X.org session, be spat back
out to the GDM login screen, or face a horrifying black screen of emptiness. If that unfortunate latter outcome happens, try switching to a TTY with Ctrl+alt+f3, logging in and running
$ sudo systemctl gdm restart
If you successfully landed in Gnome, you can check what kind of session you have landed in with:
$ loginctl list-sessions
You’ll see something like:
SESSION UID USER SEAT TTY
1 1000 lxf seat0 tty2
Then take that session number and substitute it in the following command:
$ loginctl show-session 1
Lots of information will be displayed, and fingerscrossed it includes a line:
Type=wayland
If not, check the Troubleshooting box on page 45. Any pure GTK application supports Wayland, so all of the core Gnome utilities are fine. Other things are still tied to X, so Wayland comes with its own Xwayland layer to handle these. Since this has to be a complete X Server, and since most people run at least one application that isn’t Wayland-ready, running Wayland is sometimes seen as a waste of resources. However Xwayland is slim, and only runs what is needed by the application, so this argument is fallacious. The version of Firefox bundled with Fedora 30, for example, still needs to be run with Xwayland.
Going the other Wayland
KDE Plasma now works well with Wayland, and Plasma 5.16 (which will have been released by the time you read this) should work even better. It should even support the Nvidia driver, although if the Gnome support is anything to go by, applications using Xwayland may behave erratically or misbehave entirely. Xfce is a sadder story since some of its applications still rely on GTK2, and its window manager will need to be rewritten to work with Wayland, or replaced entirely.
Weston, Wayland’s reference compositor, isn’t necessarily something you’d use as an everyday desktop replacement. But it’s great for testing, if nothing else because you can run Weston within your existing desktop and display server – although it does currently seem to run very slowly if you run it within a Wayland Gnome session on Arch. On Fedora, even if you’re only running the live session from the disc you can install and run Weston with:
$ sudo dnf install weston
$ weston
You should see a small window with a grey, neatly tessellated background. Maybe not the most exciting thing in the world, but better than nothing (indeed, you may also see nothing, or an error message). Clicking the terminal icon in the top left corner opens a terminal from which you can further explore Weston.
One feature you’ll no doubt agree is missing from all major desktops is the ability to rotate windows. But not from Weston: try hovering the pointer over the terminal’s title bar and pressing Super (the Windows key) while moving the mouse. Amazing, isn’t it? There are other exciting shortcuts too, such as changing window opacity with Super+alt and the scroll wheel.
You should be able to start a Weston session outside of your current desktop by logging out and choosing the Weston session at the password prompt. If you’re following along in Fedora’s live environment, you’ll need to set a password for the live user before quitting Gnome. The easiest way to do this is to go to the Activities view by pressing Super, then type the first few letters of users . Then click on the suggested Users applet. Now when you log out and try to log in again, you’ll be asked for a password, at which point you can choose the new Weston session. Quit Weston with Ctrl+alt+backspace when you’ve finished.
As we mentioned, there’s another, more modular approach to Wayland. This will appeal to desktop
hipsters – folks who prefer their GUIS minimal, discerning bearded types who prefer keyboard shortcuts to friendly menus, people who are more Openbox and i3 then Gnome and KDE. Oh, and people not using the Nvidia driver. Anyway, that approach is exemplified by the Sway compositor for Wayland (https://swaywm.org). Sway is a drop-in replacement for i3, which is a minimal tiling window manager. You can install it in Fedora in the usual way (which will give you quite an old version), or you could first add the copr
repo and get a newer version:
$ sudo dnf copr enable tofik/sway
$ sudo dnf install sway
You’ll be asked to accept a GPG key, which is up to you. If you do, some dependencies and the rxvt-unicode terminal program will be installed, because everyone needs a good terminal.
Sway is the brainchild of Drew Devault, aka sircmpwn. The 1.0 releases are quite exciting insofar as they introduce a new library, wlroots, which can be reused by any budding writer of Wayland desktops. It saves those individuals the burden of reproducing functions for standard tasks, as well as the not insignificant task of implementing an Xwayland layer. This is good as, besides saving effort, it might standardise bread-and-butter Wayland interfaces, avoiding the fragmentation that people so often like to complain plagues the Linux ecosystem. Quoth the Github, “about 50,000 lines of code you were going to write anyway”.
Anyway, start Sway by logging out of your current desktop and selecting it when you enter your password. You might be shocked at the minimalism, or if you’re used to i3 you’ll feel right at home. There are no menus, no Activities view and no matter where or how furiously you click, nothing will happen. However, if you press Super+return a 256-colour, Unicode-supporting terminal will duly occupy the whole screen. Press it again and another terminal will open, with the previous one courteously making room for it.
This is how tiling window managers work. You can switch focus simply by hovering over a window, and you can switch between ten (!) virtual desktops with Super and the number keys. Windows can be closed with Super+shift+q. Sway is configured per-user from
~/.config/sway/config. This directory doesn’t exist until you create it, so do that, then copy over the global config file at /etc/sway/config and customise it. We’re running out of space, so we’ll direct you to the wiki at
https://github.com/swaywm/sway/wiki to learn more about configuring and using Sway. Oh, and if you want to exit cleanly, use Super+shift+e.
We mentioned earlier that the version of Firefox bundled with Fedora 30 requires the Xwayland layer. This wasn’t the original plan. Fedora has been working on a native-wayland version of Firefox for some time, but it was deemed not quite ready for this release. It’s easy to try though, as easy as:
$ sudo dnf install firefox-wayland
The package just provides a new launcher so is a mere 19K big. See if it works for you with firefoxwayland . If you’re using Arch you can find a binary package of this in the AUR, catchily titled fedorafirefox-wayland-bin .