Migrating from X11 to Wayland and from i3 to Sway
May 15, 2022
May 15, 2022
Finally. After so long. I switched to Wayland. 🎉
I remember back when I started using Linux, more than 10 years ago now, I was already reading about Wayland, and seeing early adopters on forums using it and loving it despite running into all kinds of issues… this wasn’t for me. X11, while old and outdated, was well supported for everything I wanted to do, and that was awesome.
But the other day, I was bored or something, and I asked myself: is Wayland mainstream enough for me to use it yet?
The answer was… nearly yes. Yes enough for me to switch. And that’s a fucking good news.
In this post I’ll share with you what was needed to get a usable Wayland server running with Sway, all the Wayland alternatives to the X11 programs I was previously using, and finally how I completely purged X11 from my system.
I’m a Arch Linux user, so the commands will be adapted to that system.
Being a long time i3 user, Sway was the obvious choice as a Wayland compositor. The fact it’s compatible with my existing i3 config should ease the transition quite a lot.
pacman -S wayland sway
Then from a TTY I could just run sway, and end up in an environment
pretty close to my habitual i3! Good start.
There’s a number of X11 programs that I was using, that just don’t work on Wayland. The good thing is that the Wayland ecosystem is mature enough nowadays that there was a solid alternative for all of them!
wl-copy and wl-paste).xbacklight that helps controlling the screen backlight is now
Light.bemenumoji
script instead).There’s also a number of programs that are no longer needed:
xset that I used to set to lower the keyboard repeat delay is
replaced by the repeat_delay Sway option.So in the end, this leaves us with the following commands:
pacman -S bemenu-wayland imv grim slurp wl-clipboard light wtype gammastep
pacman -Rns dmenu feh maim xclip xsel xorg-xbacklight xdotool redshift xss-lock xidlehook xorg-xset picom
Because foot is the default terminal emulator of Sway, I decided to try it instead of my usual xfce4-terminal. That wasn’t a complete success for me and I rolled back to xfce4-terminal since it works just fine on Wayland anyways!
Finally, I had a few .xmodmaprc modifications that I use to
invert Alt and Ctrl
and also emulate Fn Lock
because it’s not supported on my laptop.
xmodmap is a X11-only thing, and I had to configure XKB directly to reproduce this behavior. XKB stands for “X keyboard extension” but it is also used by Wayland.
If you want to see the details, here’s the link to the full diff in my dotfiles.
I anchored it to the conversion from ~/.config/i3/config to
~/.config/sway/config but feel free to move around and see the other
changes I did.
I took this as an opportunity to change a few unrelated things in there so not all the modifications were strictly necessary.
Now we have a working Wayland and Sway installation, we can remove X11 altogether from the system! Or can we?
pacman -Rns xorg-server i3
Turns out this didn’t work for me. VLC, mpv, Chromium and calibre all required some X11 dependency that would be removed by this command. Bummer.
So what I did instead:
pacman -Rns xorg-server i3 vlc mpv chromium calibre
pacman -S vlc mpv chromium calibre
VLC and calibre both use Qt, and as documented on the ArchWiki,
we need to install qt5-wayland for Qt to work.
Programs built on Chromium (including Chromium itself obviously) support Wayland nearly out of the box, but they require some kind of flag to enable the support. Not really sure why this is a thing, but basically I need to start Chromium and Visual Studio Code like this:
chromium --ozone-platform-hint=auto
code --enable-features=UseOzonePlatform --ozone-platform=wayland
I use those programs once in a blue moon anyways, so I don’t really care.
I used to use xidlehook --not-when-audio to prevent dimming the
screen, disconnecting the screen, or locking the computer after an idle
period if there’s audio playing.
This is great for example when watching a movie… you don’t necessarily actively use the computer but you don’t want it to lock and suspend or hibernate while it’s playing either!
Some programs like mpv support inhibiting idle while playing, which is great, but others like VLC and Firefox don’t.
In general, the “not when audio” trick was a pretty good fallback that didn’t require any custom implementation in existing programs.
Luckily, there’s SwayAudioIdleInhibit (on the AUR) that does exactly that. Fantastic.
The only quirk I noticed with it is that in Firefox, some very specific sites like Artlist (the only one I identified so far) manage to register an active audio channel at all times even if they’re not playing anything, and as long as the tab is open, idle will be inhibited. This is not good as I tend to keep tabs around for days if not weeks!
To be able to notice when this happens more easily, I
modified my i3blocks volume block
to display a different icon whether or not there’s any PulseAudio sink
in state RUNNING.
Migrating to Wayland was a pretty smooth transition at the end of the day, and I’m glad I finally did it! Everything works great, it seems like Wayland programs are usually more recent and have better UX than their X11 equivalent that I was previously using.
For example I love the slurp screen selection, and I don’t have to patch dmenu anymore in order to support emojis, since they natively work with bemenu, and basically everything else?
Also I realized that Wayland allowed me to zoom in on any part of the screen with my trackpad out of the box, and that’s pretty useful. One of the features I was kinda missing from MacBooks but never spent the time to figure if I could do it or not with X11.
If you’ve been thinking about migrating to Wayland, it’s probably a good time to do so!