speedie-page/articles/The Wayland experience.md

# The Wayland experience

2022-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](https://spmenu.speedie.site) 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](https://git.speedie.site/speedie/dfmpeg-spmenu)
and [screenshot-spmenu](https://git.speedie.site/speedie/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!