My Plasma Wayland experience in July 2022

Last time I tried (many years ago), trying to log into the Plasma Wayland session just popped me straight back to the display manager. As it has been several years, I want to try it out again.

The computer I did this on is a conventional desktop PC with a mouse and keyboard, along with a Wacom drawing tablet. The GPU is a Radeon 460.

Overall it's the same at best and somewhat broken at worst. Although it's much better than the last time I tried (2015 if I remember right, back when GNOME 3.16 was recent) and likely a better experience for some users, for example with multiple monitors or with touch devices, it is still not ready for me.

Differences

Mouse sensitivity is a little different. This is easily remedied by turning it down a bit in System Settings, but still a little weird as I was already using libinput on X.

Nice things

Alacritty and other apps start much faster.
Almost everything remains unchanged.

Problems I faced

Keyboard rebinds are a little janky until I set the options again. Capslock → menu wouldn't work, menu → super made the key emit both super and menu. (Super = the Windows key = what Plasma calls meta.) This went away after I went into System Settings, reset keyboard options, then re-enabled them again.
The default cursor (DMZ-Black) would show up from time to time despite having changed the default.
Occasionally the wrong cursor would be used, for example the drag-and-drop cursor might be used when I'm not dragging anything.
Drawing tablet weirdness
Drawing tablets are considered a different pointing device in Wayland, which sure, fair enough. But it's still incredibly janky.
Drag-and-drop doesn't work. Plasma's startup animation show up in the wrong place. Menus open in the wrong place until a mouse has interacted with them.
The menus open incorrectly until a mouse has interacted with them.

(my fault) My Emacs config assumed X11 and therefore broke under Wayland

Trying to connect to my Emacs daemon makes it return “Authorization required, but no authorization protocol specified”. This is a problem with my config: I have a k/set-display-if-empty hack that makes it possible for an Emacs daemon started in a systemd user unit to send notifications under X when there isn't a graphical frame open.

(defun k/set-display-if-empty (&optional _)
  "Set the environment variable DISPLAY to \":0\" if it's not set.

This allows running X related stuff even when there's no frame active."
  (unless (or (getenv "DISPLAY")
              (getenv "WAYLAND_DISPLAY"))
    (make-thread
     (lambda ()
       (while (not (getenv "DISPLAY"))
         (setenv "DISPLAY" ":0")
         (sleep-for 2))))))

(dolist (hook '(delete-frame-functions
                after-init-hook))
  (add-hook hook #'k/set-display-if-empty))

When Emacs is started with a systemd user unit, it does not inherit environment variables from the desktop environment, so without this notify-send wouldn't work if there is no active frame.

You can see me trying to avoid setting DISPLAY if Emacs is started under Wayland. The problem is that WAYLAND_DISPLAY is also not inherited, so I still end up setting DISPLAY under Wayland, which presumably makes Emacs attempt to connect to a nonexistant X server.

This is the solution:

(defun k/set-display-if-empty (&optional _)
  "Set the environment variable DISPLAY to \":0\" if it's not set.

This allows running X related stuff even when there's no frame active."
  (unless (or (getenv "DISPLAY")
              (getenv "WAYLAND_DISPLAY"))
    (make-thread
     (lambda ()
       (if (getenv "WAYLAND_DISPLAY")
           (setenv "DISPLAY" nil)
         (while (not (getenv "DISPLAY"))
           (setenv "DISPLAY" ":0")
           (sleep-for 2)))))))