I decided it is time to test Wayland on my 11th Gen Intel CPU/GPU (Iris Xe Graphics).
ArchLinux wiki has some extensive documentation about that, but making aeverything working is a different thing.
I am not going to discuss the pros and cons of Wayland-based implementations versus X.org ones as this could end up in a religion war!
This is a “from scratch” approach as I was also installing my PC from zero (after a complete backup).
Installation
As usual I follow the official installation guide (I don’t feel ready yet for archinstall) and install a part of my packages straight from the pacstrap step. It looks lije this:
pacstrap /mnt base linux-zen linux-firmware openssh vim intel-ucode xfsprogs \
grub dosfstools sudo networkmanager dhcpcd efibootmgr wget make fakeroot \
pkgconf man-db plasma-wayland-session konsole networkmanager patch gcc \
wayland kwin xorg-xwayland qt5-wayland plasma-desktop xorg-xlsclientsAt the end of the installation I get a failry minimal KDE/Plasma installation.
The package xorg-xwayland is actually a “bridge” to run X.org programs under Wayland without the need of a fully blown X.org installation, while xorg-xlsclients is a tool that will list all programs running as an X.org client. As usual, a number of dependencies are pulled along, all from the official repositories (no AUR at this stage).
In order to startup KDE/Plasma under Wayland we need a suitable display manager. It it was still X.org, my default choice was sddm. But, as of today (0.19.0-8), it doesn’t fully support Wayland. It will do on version 0.20 . So I chose something rather “unusual“: tbsm.tbsm is a bash-only, text based “window manager” that can startup our KDE/Plasma session from the console. This means that I forst need to log in via text console, then start KDE.
Moreover, tbsm needs to be installed from AUR. I like the idea of something writtend just in bash, at least until sddm doesn’t update.
To use tbsm I modified my .bashrc by appending a line like this (after all other bash environment setup):
[[ -n "$XDG_VTNR" && $XDG_VTNR -le 2 && "$XDG_SESSION_TYPE" == "tty" ]] && tbsm || trueIt “simply” starts tbsm script only when logging in from local console (session type is tty) in either one of the first two virtual terminal numbers. The trailing true is to avoid non-zero return code in case, for example, of remote login or shell statrup from a graphical terminal (see my other article about shell prompt).
Testing
In order to test eveything I open a konsole session and run xlsclients. It shows nothing, so konsole itself is running natively undewr Wayland. My faithful ps command shows me that the magics is actually done by the KDE stacking compositor: kwin:
[enzo@Feynman ~] ps ax | grep -i wayland
0badc0de 625 624 S - 41 RR 1.7 194124 - /usr/sbin/kwin_wayland --wayland-fd 5 --socket wayland-0 --xwayland-fd 6 --xwayland-fd 7 --xwayland-display :0 --xwayland-xauthority /run/user/1000/xauth_vqfziA --xwaylandSo far, so good. Same goes for the KDE-native chromium-based browser: falkon.
Now I install and startup a non-KDE browser: Firefox. This time xlsclients shows it. This means that it is actually working under the xorg-xwayland bridge.
A quick search returns me the workaround. I modify the startup command from the KDE menu to force firefox use its built-in Wayland support so it now looks like this:
[[ "$XDG_SESSION_TYPE" == "wayland" ]] && MOZ_ENABLE_WAYLAND=1 /usr/lib/firefox/firefox %u || /usr/lib/firefox/firefox %uInstead of the plain simple default:
/usr/lib/firefox/firefox %uOnce saved, I close and restart Firefox and this time xlsclients doesn’t show anything: Firefox is natively using Wayland!
Next steps are chromium and vivaldi browsers. Both have builtin Wayland support, but the startup command fix is slightly different from Firefox’ as we need specific command line options:
[[ "$XDG_SESSION_TYPE" == "wayland" ]] && /usr/bin/chromium --enable-features=UseOzonePlatform --ozone-platform=wayland %U || /usr/bin/chromium %UWe could embed those in a file but we’d then loos the “dynamic” nature of the decision. If for any reason we haven’t Wayland enabled, the configuration filewould become invalid. Instead, the use of an implicit conditional (those [[ and ]] and the || and && operators) make the magics for us!
Last but not least, my beloved graphical code editor (with vim being my favorite general-purpose text editor).
The OSS version of Visual Studio Code, called code has no builtin support for Wayland. But luckily, the AUR contains a version with it. It is called aur/code-wayland and is slighlty lagging behind its older brother community/code . But this seems to be just a minor sin.
0BAD-C0DE 