My first impression of and experiences with Wayland

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.


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




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.

tbsm on tty3 (the friendly Linux penguin brought to you by /etc/issue)


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!


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.