Ever since I watched this talk by Carsten Haitzler, I wanted to try out Xorg’s unofficial (?) successor, Wayland. In a nutshell, it is supposed to be much more secure than Xorg (e.g., against keyboard loggers) and its architecture easier to extend and maintain. Its downsides are supposedly less network transparency (which in over 20 years of using Linux, never played a big role for me anyway) and, depending on who you ask, no closed-source driver support.
My first impression of it: Wayland has become very usable by now. Within 15 minutes or so, I had it up and running on my Debian unstable.
Compositors
Wayland does not know the concept of a window manager. It uses what
it calls compositors, and thankfully there is the
Sway compositor, which behaves more or less
like the i3 window manager, which I use under
Xorg. Wayland also provides a more mainstream compositor, Weston. So
if a tiling window manager is alien to you, you can start Weston
instead and feel right at home. But in order to be able to do that,
you will need a login manager that allows you to start a Wayland
session at all, and not every login manager is able to. It is
relatively easy though to find one that is. I have chosen
tbsm, a login manager for the
console, which naturally requires you to disable all other login
managers first, for example, by replacing in /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
with
GRUB_CMDLINE_LINUX_DEFAULT="text"
In terms of stability and performance, Wayland felt on par with Xorg, although I am not a gamer who challenges his PC much in that regard.
Compatibility
If you want to open X-programs that are not natively Wayland-aware (which most programs aren’t), you’ll also need to install xwayland, which is Wayland’s wrapper around the Xorg-server for compatibility reasons. Without it, you may not even be able to open a text window when you start Wayland for the first time!
Problems
The biggest issue I faced was the lack of xmodmap and xsession
support. Everything from ~/.xsession had to be migrated into
~/.config/sway/config, which is OK, but means it’s not available to
other compositors that I may use in the future. ~/.xsession was
universal in that regard when you chose the default session in your
login manager.
While the xsession-issue was somewhat inconvenient, it wasn’t exactly
a deal breaker. Lack of xmodmap support, however, was. Until today, I
have not found out how to remap keys in xkb, so that I can type German
Umlauts using Ctrl + a for ä or Ctrl + Shift + o for
Ö, etc. By using
setxkbmap -model pc101 -layout us -variant intl -option lv3:ralt_switch,terminate:ctrl_alt_bksp -print
I ended up with the right Alt key and q giving me ö, but with
Shift it’s not an Ö, but the same keystroke that both i3 and Sway
use to close a window - and I do not want to remap this. I’ve
outgrown the urge to wildly remap programs’ default behaviours, just
because I can.
Also, I’ve asked this question on Stackexchange, but with 0 replies so far. Hence, I’m back on Xorg - for now. But I’m guessing that it’s not long until these types of rough edges are evened out, and also people who don’t want to study xkb’s source code are able to switch to the more secure Wayland for good.