A couple of days ago, I decided to give Wayland a go. For those of you who live under a rock, Wayland is meant to be the successor of X11, the traditional graphical server/protocol in the GNU/Linux world, responsible for things such as drawing windows on your screen, passing keyboard and mouse events to the correct programs, etc. (I live under a rock too, but sometimes I stretch my head out to see what is going on in the world, only to crawl back not long after.)
Like with most technology transitions, there is a lot of drama going around Wayland vs. X11 and their respective merits and demerits. Reading such discussions can be quite frustrating; not only people can have widely different usage and requirements from graphics functionality – gaming (with different kinds of games), watching videos with varying resolutions and refresh rates, different graphics cards, accessibility settings, desktop environments, etc. –, but people can also differ in how they perceive little functionality changes just because of variation in how their eyes or brains work. A relatively minor glitch (such as screen tearing while playing a video, a couple milliseconds extra delay to process a keystroke in a game, or a font that renders slightly differently) can be a huge annoyance to one person, barely noticeable to another, and literally invisible to a third one. The result is that such discussions feel like people are talking past one another, unable to understand why others would make a different choice from them and insist on being wrong on the internet. People in the GNU/Linux world are also used to enjoying immense freedom to choose, customize and build their own desktop environments, which also contributes to the wide variety of experiences and difficulties in switching from one graphical stack to another.
If you want to understand why Wayland exists, you can watch The real story behind Wayland and X, a Linux.conf.au presentation by Daniel Stone, a Wayland and former X.org developer. Basically, X.org contains a huge number of features that are not used by modern clients but have to be kept around for compatibility, and limit the ways in which problems with X can be solved. Originally, the X server used to be responsible for font rendering, drawing graphical primitives, and a variety of other functions that nowadays are done by the clients themselves; modern clients usually just want to send a fully rendered image for the server to display. All the old cruft accumulated across the four decades of X11’s existence make it hard to maintain for developers.
One thing that is noticeable in these discussions about X11 vs Wayland is that one hears a lot from X11 users defending X11, Wayland users defending Wayland, Wayland developers defending Wayland, but not much from X11 developers. The main reason for this is that X11 developers are Wayland developers by and large. The X.org server is pretty much in maintenance mode, and much if not most of development that still goes on in the xserver repo is related to Xwayland, the compatibility layer that allows X11 clients to run on Wayland. As much as we may like X.org, if developers don’t want to work on it, there’s not much we can do about it (and it seems that it’s pretty hard for new developers to get started on it, due to the accumulated complexity). Granted, X.org isn’t going away any time soon, but it’s also not going anywhere. Regardless of the technical merits of Wayland vs. X11, it seems pretty clear that Wayland is the future going forward.
So far I have stayed in the comfort of my old X11 setup, mainly because I had no reason to put an effort into switching. A reason finally showed up, though: on my current laptop (a ThinkPad E14 4th generation), I see quite a bit more tearing while watching videos than on my previous PCs. Although it is within the range of what I can live with (after all I’ve been using this computer for almost a year like this), all else being equal, it’s something I would like to get rid of.
The first step into switching to Wayland is picking a compositor: the application responsible for managing windows and drawing on the screen. On X11, the window manager and the X server are two different programs; on Wayland, both of these roles are taken by the compositor. The idea here is to cut out the middleman since (1) nowadays the graphics card driver lives in the kernel, which exposes it as a framebuffer device, unlike in the olden days where you would have different X drivers to handle different graphics cards, and (2) most modern window managers do compositing anyway, so instead of having the window manager composite the image of the whole desktop, then give it to X to draw it on the screen, the compositor can write it directly to the graphics card.
This means that there are effectively as many Wayland servers as
there are window managers out there. This is annoying because the
compositor is not only responsible for managing windows, but also
handling input devices, keyboard layouts, accessibility features,
clipboard, and a variety of other things that were traditionally handled
by the X server. Each compositor has to implement these features on its
own, and although there are common libraries that are used by different
compositors to implement some of these features (e.g.,
libinput), there is often no standard way to access those
features that is portable across different compositors. For
instance:
There is no standard way to change the keyboard layout in
Wayland, the way you can with xkbcomp or
setxkbmap in X. In Sway
(the compositor I picked, a Wayland port of i3),
one can use
swaymsg input type:keyboard xkb_file path/to/keymap.xkb
(among other xkb_* options) to load a new keymap; other
compositors may have other commands.
There is no standard way to control screen resolution and
position (i.e., xrandr). There is wlr-randr
for wlroots-based compositors (from
reddit), but other compositors use different things.
There is no standard way to get a list of all open windows and
switch focus to one (i.e., wmctrl). I have a script bound
to Super+g to present a list of windows for selection with
dmenu and jump to one of them, which will require
adaptation. In Sway, one can use swaymsg -t get_tree (which
returns a nested tree that requires quite
a bit of contortion to turn into a flat list, at least from a shell
script); other compositors may have other solutions.
Some of these features may end up being standardized as protocol extensions (see wlr-protocols and wayland-protocols), but which protocols will be supported by each compositor will vary. This feels like the situation in Scheme with its various SRFIs that different implementations may or may not support, or XMPP where support for a feature depends on the client and server supporting the desired set of extensions. I suppose the situation will improve in the upcoming years as the set of protocol extensions gets more standardized, but the current situation is this. The thing is that this is a non-issue in X: new window managers don’t need to care about any of this, because the X server handles these the same way regardless of what is your window manager.
As soon as I open the Sway session and start up lxterminal, I notice
an issue: lxterminal on Wayland is not honoring my
FREETYPE_PROPERTIES='truetype:interpreter-version=35'
environment variable. This setting changes the font rendering algorithm
such that fonts look crispier, especially in non-HiDPI displays. This is
well within the “some people won’t even notice” category, but for me the
difference is noticeable (particularly in my external display), it took
me ages to figure out this setting existed, and I’m not willing to give
it up easily (at least not until I switch to an HiDPI external display,
something that probably won’t happen within the next couple of years). I
noticed that Emacs did not suffer from this issue, but it turns out
Emacs was running under Xwayland. It’s nice indeed to see that X11 apps
run seamlessly enough under Wayland that it took me some work to realize
that it was running under Xwayland and not natively. (I figured
it out by calling xprop: it only reacts to clicks on X11
windows.) I installed foot, a lightweight native Wayland
terminal that is recommended by the sway package on Debian,
and it also suffers from this issue. So it seems to be a general issue
with Freetype under Wayland, which is weird because font rendering
should be a client-side problem and should be the same under X11 and
Wayland.
Finally, I tried to start up the NetworkManager applet. Just running
nm-applet won’t show anything, because by default
nm-applet uses the Xembed protocol to create a tray icon,
which is not supported by Swaybar; you have to run
nm-applet --indicator instead. However, clicking on the
icon does nothing; it seems that the context menu on tray icons is currently
not supported (as of Sway 1.7). It does work with Waybar (and the context
menu has the same font rendering issue; in fact I’m not even sure it’s
using the same font), but Waybar has a lot more bells and whistles I’m
not interested in, plus I would have to figure out how to adapt my
current status bar script to it (assuming it’s possible), which is
pretty important to me as I use the i3 status bar to display desktop
notifications.
The lack of Xembed tray icon support is a problem for another program I use as well: Thunderbird. As of 2023, I’m still using Thunderbird 52 (released in 2018) because it’s the last version that supports FireTray, which shows me a glorious tray icon with a number of unread messages whenever there are unread messages in selected folders, and no icon otherwise. I know that one day I will probably have to switch to a different mail client and/or workflow, but that day is not going to be now.
It does eliminate screen tearing, though. But also it turns out I
could fix that on X.org by using picom --backend glx
--vsync. [Update: Actually that doesn't fully fix it,
and sometimes causes other glitches of its own. Wayland wins in this regard.]
In The technical merits of Wayland are mostly irrelevant, Chris Siebenmann argues that everyone who would switch from X to Wayland by virtue of its technical merits has already switched. The people who haven’t done so fall into a bunch of categories, one of which is:
People using desktop environments or custom X setups that don’t (currently) support Wayland. Switching to Wayland is extremely non-transparent for these people because they will have to change their desktop environment (so far, to GNOME or KDE) or reconstruct a Wayland version of it.
I happen to be in this category. Sway can mostly replace i3,
but then I have to find a replacement for nm-applet (or use Waybar and
change my status bar script), a replacement for FireTray, rewrite my
jump-to-window script, figure out what the heck is going on with the
font rendering, change my scripts that currently use
xrandr, etc. All of this to get a desktop just as
good as my current X11 one; switching to Wayland does not really
bring me any new functionality or improvements. Maybe a few years from
now, as X.org starts to bit-rot and new stuff starts to be developed for
Wayland exclusively, switching will become more compelling. As of 2023,
though, I don’t really have much to gain from it, and I’d rather spend
my time on other adventures, at least for now.
But I don’t share the Wayland hate I see in various places around the interwebs. When the time comes (or when I feel like it), I will make the switch. By then, hopefully some of the issues above will have been fixed (e.g., more standardized protocol extensions, menu support for Swaybar tray icons), hopefully I will have found a replacement for FireTray, and maybe I will have switched to a HiDPI external monitor. Until then, long live X.org.
Yeah, I've been thinking about KDE lately. I haven't used a full desktop environment for ages (I started using EXWM around 2017, and i3 in 2020), and I won't switch to a non-tiling window manager any time soon, but maybe KDE with some tiling addon might be worth a try (I found this one: https://github.com/Bismuth-Forge/bismuth). Thanks for your comment!
Copyright © 2010-2024 Vítor De Araújo
O conteúdo deste blog, a menos que de outra forma especificado, pode ser utilizado segundo os termos da licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.
Powered by Blognir.
manemobiili, 2023-11-09 03:48:39 +0000 #
I used to rock ratpoison, sdorfehs, stumpwm and xmonad until doing stuff with obs-studio, and it brought me into wayland.
It started off with sway and gnome but i wasn't happy with them. Kde feels really mature now and it gets out of my way. I don't have any bars or decorations on my desktop. Keyboard shortcuts are sensible and easy to customize. But in the end all i want it to do is:
1. Launch applications: alt+space
2. Maximize windows: super+uparrow or f11
3. Switch between windows: alt-tab