11 KiB
The Wayland experience
2023-06-17
Today I want to talk about my experience using Wayland compositors and software,
as well as developing Wayland clients for Wayland using the wayland-client library.
I've talked about the protocol itself in the past, usually in a negative light
because that's how I see it for the most part, but after using Wayland for a bit
I have some more things to say about it, and I want to talk about those today.
First of all, Wayland is not a display server, just like X11 isn't a display server. X11 and Wayland are both display protocols, which then have to be implemented. X11 has a standard implementation, called Xorg. While this isn't the only implementation of the X11 protocol, it is by far the most used one. This is called a display server. Wayland on the other hand does not have a single implementation more popular than others, because each compositor has to implement the Wayland protocol themselves. This can lead to issues if a compositor doesn't implement a core part of the protocol. This means the compositor is also the display server. But because implementing an entire display server and following the Wayland spec is complicated and time consuming, libraries such as wlroots and swl have been created, which implement a lot of the Wayland functionality for you. This is really as far as standards go with Wayland, because every Wlroots based compositor is compatible with each other. The problem now is everyone is going to base on Wlroots, and for good reason because no one really wants to write all that code.
Except not everyone wants to use Wlroots. For example GNOME and KDE both have their own Wayland implementation (because of course they do), and this leads to problems such as software only being written to work with Wlroots based compositors or GNOME/KDE. From a developer's perspective, you can't just leave out GNOME because GNOME is incredibly popular and used by a very significant amount of GNU/Linux users, but at the same time if you leave out Wlroots based compositors a lot of power users aren't going to be able to use the software on their favorite compositor, so no power users are going to be using the software. So the developer has to support BOTH GNOME and Wlroots, and most likely also test on both Wlroots and GNOME, unless the program has a significant enough userbase. GNOME has a history of doing their own thing instead of following a standard, and making decisions that only benefit GNOME and no one else, which is likely why they implemented their own version of the Wayland protocol. Whether that's true or not doesn't matter, because right now there's no standard implementation of the Wayland protocol, leading to more work for the developer.
As you probably know, about two weeks ago I finished porting my program spmenu over to Wayland. While I was working on the port however, I almost immediately noticed how lacking Wayland really is in terms of features. They claim this is for "security", but I don't buy this argument for several reasons. spmenu has a feature to position itself at a specific X or Y position on the screen, but in the name of security wayland-client (the library used to create Wayland clients) does not allow you to do this. I ended up disabling this feature in the final product, which really should not have to be done. I get that this can't be done with a standard window, but this is a layer window, meaning it's supposed to be layered above all other windows, so it makes sense to allow it to be placed anywhere.
The reason I don't think security is a valid excuse here, is because with the wlr-layer-shell protocol you can grab the keyboard and (almost) all input, and grab the focus all to yourself. That's a much higher security risk than allowing the window to position itself anywhere. Instead of allowing a specific position, we instead have anchors, allowing us to anchor the window to a predefined part of the screen, such as top, bottom and center. Also, if you have programs doing malicious things by positioning itself, you have a much bigger problem. Wayland does do some things in the name of security that I think are somewhat justified, such as not allowing a client to move another client, or read keystrokes when the program isn't actually used. That's very useful for keylogging and other nasty things. But at the same time, if you have malware on your computer, then you have bigger problems than that, and there are legitimate uses for logging keys or moving other clients, which now aren't going to be possible anymore in the name of security.
Alright, so we've established that Wayland has fewer features than X11, how could things get any worse? GNOME has the answer to that. Because there's no standard implementation, you can just choose not to implement certain features. wlr-layer-shell is a unstable protocol, but despite this it's the only way to create a run launcher that functions like.. a run launcher, at least on the Wlroots implementation of Wayland. GNOME however doesn't implement wlr-layer-shell so any programs that use wlr-layer-shell will not function under GNOME, and spmenu is no exception to this. It doesn't make it any better that GNOME has a very high authority over the direction Wayland is going in, and really the direction GNU/Linux as a whole is going in.
Okay, but what's Wayland really like to use for the average user? Mixed, let's just say that. If you're using a desktop environment, chances are you don't even notice any difference between it and the same desktop environment on X11, at least none that isn't positive. If you're using a window manager on the other hand, you're going to notice things right away. Many programs that you may be using just will not function anymore, particularly the programs that capture the display. Wayland shills will claim that Wayland has support for all your X11 programs, but while that's not entirely false, anything that captures the screen itself is going to be totally broken on Wayland.
One thing I noticed fairly quickly is that screenshotting doesn't work.
I'm using a tool called maim for this, and maim is X11 specific. Great, use
XWayland right? XWayland doesn't work for this purpose, and as a result the
capture is just black. What about ffmpeg and x11grab? Nope, doesn't work and
all you get is a black screen. Turns out on Wayland you need Pipewire
(or another tool) to capture the screen, and ffmpeg doesn't support this,
so if you had plans of using Wayland and at the same time using ffmpeg to
capture your screen, you're out of luck. While replacements for the X11
specific software does exist, much of it is very buggy, broken, not in
repositories or just not the same thing. Recording using ffmpeg can be
replaced using a command line utility called wf-recorder, but screenshots
are little more complex.
On Arch, you need to manually compile a program called wayshot (a program that
functions as a maim replacement) because the version you can get from the AUR
is out of date and doesn't support using slurp (a slop replacement), meaning
you can't select. After that though, everything works pretty much as expected.
But what about copying the image to the clipboard? Well, on X11 we can just
pipe the image into xclip -sel clipboard -t image/png, but as you might expect
this isn't built to use Wayland natively. It does work, at least with XWayland
compatible compositors but to do it natively you'll want a replacement called
wl-clipboard and the wl-copy command. The wl-copy command works pretty much
in the same way, pipe the image or text into it. Unlike with xclip though, you
don't need to specify a type, and wl-copy only supports one clipboard so you
don't need to specify a selection either.
Normal X11 programs though that run in a normal window or floating window usually work fine, and I was able to carry on using my X11 terminal emulator which is st just fine, with no noticeable loss in speed. No configuration is required for these to function with most compositors, although some don't support XWayland such as Qtile, so with those you may not be able to use your X11 specific programs.
What about Wayland compositors? Most of them are terrible in my experience. Maybe there's some secret awesome compositor, but every single one I have used so far has had some major flaw that makes it unusable. I started off my Wayland journey on Hyprland because I hear that's what most people use. The default keybinds are absolutely awful, and a good example of that is Super+q which doesn't quit Hyprland or close a window, but rather spawns Kitty, which isn't even a Wayland specific terminal emulator. Certainly a weird default. Even after some configuration though, Hyprland has several issues. For one, if you set a wallpaper using swaybg or hyprpaper the computer runs much slower, and Chromium seems to freeze at random. This happens with all my computers, with both Intel graphics and AMD graphics. I ended up determining that it was a problem with Hyprland because with dwl,sway and river everything worked perfectly with a wallpaper set. Most of these compositors also do not have a built in bar, sway is the only one I found that has one, not even dwl which is supposed to be a dwm clone has a built in bar, despite using way more lines of code than the original dwm.
Wayland has several issues as well that make the entire product completely
unusable. For one, I have never been able to get it to work on my NVIDIA
GPU (GTX 1060 6GB) system. Not with the free software driver and not with the
nonfree nvidia driver. It's possible it works with GNOME or KDE,
but I have no interest in running any of those, and I don't care for desktop
environments. While it isn't fair to blame Wayland or Wlroots for this,
in practice I'm unable to use Wayland on my NVIDIA system, and as such I decided
it was worth mentioning.
By the way, I should also mention that I have implemented Wayland screen capturing into dfmpeg-spmenu and screenshot-spmenu if you want to use spmenu for screenshots or screen recording. This is also X11 compatible, so you don't need to switch script whenever you switch back to X11.
Anyways, I'm done with Wayland as of now. I will keep a session around to try out my own software in and will continue to support Wayland in spmenu, but I will not use Wayland anymore, and I am very happy to go back to dwm and X11. I may eventually make a second part to this blog post where I talk about actual code and programming in C for Wayland, but I'm going to end this blog post here. If you had an interesting experience with Wayland or thoughts on Wayland, feel free to share it with me. Thank you for reading, have a good day!