I do not yet use Wayland, mostly because switching away from Xorg requires work, but I am also not convinced it's worth the cost.

After reading this blurb on LWN, I decided to at least document the situation here. The actual quote:

It’s amazing. I have never experienced gaming on Linux that looked this smooth in my life.

... I'm not a gamer, but I do care about latency. The longer version is worth a read as well.

The point here is not to bash one side or the other, or even do a thorough comparison. I start with the premise that Xorg is likely going to go away in the future (think 20 years) and that I will somehow need to adapt. So this is a quick tour of my current (Sept 2022) desktop to see what needs adjusting.

  1. Window manager: i3 → sway
  2. Status bar: py3status?
  3. Web browser: Firefox?
  4. Email: notmuch
  5. News: feed2exec, gnus
  6. Editor: Emacs a blocker
  7. Backups: borg
  8. Color theme: srcery, redshift → gammastep?
  9. Terminal: xterm → ???
  10. Launcher: rofi → wofi? xdotool a blocker
  11. Image viewers: geeqie → ?
  12. Screensaver: xsecurelock → swaylock?
  13. Screenshot: maim → grim, pubpaste a blocker
  14. Screen recorder: simplescreenrecorder → wf-recorder
  15. RSI: workrave → ???
  16. Other apps
  17. X11 / Wayland equivalents
  18. Debugging tricks
  19. Other lists

Window manager: i3 → sway

This seems like kind of a no-brainer. Sway is around, it's feature-complete, and it's in Debian. Presumably, one can probably just reuse their i3 config directly as well?

Status bar: py3status?

I have invested quite a bit of effort in setting up my status bar with py3status. It seems like it has support for Sway directly, and might not actually require any change.

Web browser: Firefox?

Firefox has had support for Wayland for a while now, with the team enabling it by default in nightlies around January 2022. It's actually not easy to figure out the state of the port, the meta bug report is still open and it's huge: it currently (Sept 2022) depends on 76 open bugs, it was opened twelve (2010) years ago, and it's still getting daily updates (mostly linking to other tickets).

So who knows... I guess we can assume this just works already? To test, try:

MOZ_ENABLE_WAYLAND=1

To make the change permanent, add this to an environment startup script:

if [ "$XDG_SESSION_TYPE" == "wayland" ]; then
    export MOZ_ENABLE_WAYLAND=1
fi

Email: notmuch

See Emacs, below.

News: feed2exec, gnus

See Email, above, or Emacs in Editor, below.

Editor: Emacs a blocker

Emacs is being actively ported to Wayland. According to this LWN article, the first (partial, to Cairo) port was done in 2014 and a working port (to GTK3) was completed in 2021, but wasn't merged until late 2021, that is: after Emacs 28 was released (April 2022). So we'll probably need to way for Emacs 29 to have native support there.

Still, like many X11 applications, Emacs will probably work fine under Xwayland anyways. I suspect I will have problems with the clipboard and X selection, unfortunately. Scaling is also apparently an issue in that configuration as well. I have heard anecdotal evidence of hard lockups with Emacs running under Xwayland as well.

Backups: borg

Mostly irrelevant, as I do not use a GUI.

Color theme: srcery, redshift → gammastep?

Srcery could remain as a color theme, in general.

Redshift is another story: it has no support for Wayland out of the box, but it's possible to apply a hack on the tty before starting Wayland, with:

redshift -m drm -PO 3000

This tip is from the arch wiki which also has other suggestions for Wayland-based alternatives. Both KDE and GNOME have their own "red shifters", and for wlroots-based compositors, they (currently, Sept. 2022) list the following alternatives:

Terminal: xterm → ???

One of the biggest question mark in this transition is what to do about Xterm. After writing two articles about terminal emulators as a professional journalist, decades of working on the terminal, and probably using dozens of different terminal emulators, I'm still not happy with any of them.

This is such a big topic that I actually have an entire blog post specifically about this.

Launcher: rofi → wofi? xdotool a blocker

rofi does not support Wayland. There was a rather disgraceful battle in the pull request that led to the creation of a fork (lbonn/rofi), so it's unclear how that will turn out. Given how relatively trivial that problem is, there is of course a multitude of options:

Tool In Debian Notes
alfred yes general launcher/assistant tool
bemenu yes inspired by dmenu
cerebro no Javascript ... uh... thing debian
dmenu-wl no fork of dmenu, straight port to Wayland
Fuzzel ITP 982140 dmenu/drun replacement, app icon overlay
gmenu no drun replacement, with app icons
kickoff no dmenu/run replacement, fuzzy search, "snappy", history, copy-paste, Rust
krunner yes KDE's runner
mauncher no dmenu/drun replacement, math
nwg-launchers no dmenu/drun replacement, JSON config, app icons, nwg-shell project
Onagre no rofi/alfred inspired, multiple plugins, Rust
πmenu no dmenu/run rewrite
Rofi (lbonn's fork) no see above
sirula no .desktop based app launcher
Ulauncher ITP 949358 generic launcher like Onagre/rofi/alfred, might be overkill
wmenu no fork of dmenu-wl, but mostly a rewrite
Wofi yes rofi rewrite
yofi no dmenu/drun replacement

The above list comes partly from https://arewewaylandyet.com/ and awesome-wayland.

I have read some good things about bemenu, fuzzel, and wofi.

A particularly tricky option is that my rofi password management depends on xdotool for some operations. At first, I thought this was just going to be (thankfully?) impossible, because we actually like the idea that one app cannot send keystrokes to another. But it seems there are actually alternatives to this, like wtype or ydotool, the latter which requires root access. So who knows how well any of that actually works...

Image viewers: geeqie → ?

I'm not very happy with geeqie in the first place, and I suspect the Wayland switch will just make irritating things (no image copy-paste) worse or downright impossible.

Alternatives:

Screensaver: xsecurelock → swaylock?

I'm currently using xss-lock and xsecurelock as a screensaver, with xscreensaver "hacks" as a backend for xsecurelock.

The basic screensaver in Sway seems to be based on swayidle and swaylock. It's interesting because it's the same "split" design as xss-lock and xsecurelock...

That, unfortunately, does not include the fancy "hacks" provided by xscreensaver, and that is unlikely to be implemented upstream.

Other alternatives include gtklock and waylock (zig), which do not solve that problem either.

It looks like swaylock-plugin, a swaylock fork, which at least attempts to solve this problem, although not directly using the real xscreensaver hacks. swaylock-effects is another attempt at this, but it only adds more effects, it doesn't delegate the image display.

Screenshot: maim → grim, pubpaste a blocker

I'm a heavy user of maim (and the package maintainer in Debian). It looks like the direct replacement to maim (and slop) is grim (and slurp). There's also swappy which goes on top of grim and allows preview/edit of the resulting image, nice touch.

See also awesome-wayland screenshots for other alternatives: there are many, including X11 tools like Flameshot.

One key problem here is that I have my own screenshot / pastebin software which will need an update for Wayland as well, see pubpaste.

Screen recorder: simplescreenrecorder → wf-recorder

I am currently using peek or simplescreenrecorder for screenshots. The former will work in Wayland, but has no sound support. The latter has a fork with Wayland support but it is limited and buggy ("doesn't support recording area selection and has issues with multiple screens").

It looks like wf-recorder will just do everything correctly out of the box, including audio support (with --audio, duh).

One has to wonder how this works while keeping the "between app security" that Wayland promises, however... Would installing such a program make my system less secure? To be investigated.

Many other options are available, see the awesome Wayland screencasting list.

RSI: workrave → ???

Workrave has no support for Wayland. activity watch is a time tracker alternative, but is not a RSI watcher. KDE has rsiwatcher, but that's on the heavy side.

SafeEyes looks like an alternative at first, but it has many issues under Wayland (escape doesn't work, idle doesn't work, it just doesn't work really). timekpr-next could be an alternative as well, and has support for Wayland.

Other apps

This is a constantly changing list, but for now it seems like I'll need to:

X11 / Wayland equivalents

For all the tools above, it's not exactly clear what options exist in Wayland, or when they do, which one should be used. But for some basic tools, it seems the options are actually quite clear. If that's the case, they should be listed here:

X11 Wayland In Debian
autorandr kanshi yes
xdotool wtype yes
xev wev yes
xlsclients lswt no
xrandr wlr-randr yes

Debugging tricks

The xeyes (in the x11-apps package) will run in Wayland, and can actually be used to easily see if a given window is also in Wayland. If the "eyes" follow the cursor, the app is actually running in xwayland, so not natively in Wayland.

You can tweak the display latency in wlroots compositors with the max_render_time parameter, possibly getting lower latency than X11 in the end.

Other lists

Created . Edited .