Wayland support in kpsh

Recently, after over 10 years of its existence, I decided to give Wayland a try and replace my old and a little rusty setup. There were several things which I had to fix (I’ll write about them another time) and among them, unfortunately, was kpsh.

If you’re wondering now how the heck a console program can be incompatible with graphical environment, here’s how. To avoid copy-pasting of credentials, kpsh offers users ability to auto type them. Under the hood kpsh uses xdotool, which is X11-specific application, so under Wayland it can only type to XWayland windows.

With 0.4 and 0.5 releases of kpsh I have added support for other, Wayland-friendly backends: ydotool and wtype. Now kpsh by default detects working environment and selects appropriate backend: xdotool for X11 sessions and ydotool for Wayland.

Instead of relying on autodetection, we can force a particular backend with autotype --backend <name> switch. Unfortunately, it may still be not enough. Wayland support in many programs, most notably in mainstream browsers, is still in its infancy. This situation leaves us with a mixture of Wayland and XWayland windows. This is when --backend-cmd comes into play: it runs the passed command which dynamically determines the backend program. This way kpsh can use, for example, switch between xdotool and wtype, depending on window type. This approach is better than running universal ydotool all the time because xdotool and wtype provide much better user experience1.

As an example and a proof of concept, kpsh ships with a script which detects focused window type on Sway: kpsh-detect-backend-sway. I use it daily with kpsh-menu and couldn’t be happier:

kpsh-menu \
  -c "Autotype::autotype '{}' -B kpsh-detect-backend-sway::n" \
  -c "Username::autotype '{}' -s {USERNAME} -B kpsh-detect-backend-sway::ln" \
  -c "Password::autotype '{}' -s {PASSWORD}::ln -B kpsh-detect-backend-sway"
  -n 'notify-send kpsh-menu "{cmd}"'

You can download new versions of kpsh from pypi and its source code from git.


  1. Ydotool requires access rights to /dev/uinput, so typically a root access, and has problems with typing unicode characters. Without ydotoold it sometimes looses characters and ytdotoold itself is a little buggy (which is the eupheism for: it crashed all the time).