161 lines
11 KiB
Markdown
161 lines
11 KiB
Markdown
# 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!
|