xcape
xcape copied to clipboard
alols
wayland support
Not really an issue I guess but currently testing wayland, I find myself cruelly missing xcape !!
Since I have absolutely no idea how the same could be achieved in wayland, I try asking here...
Cheers,
Christophe
This is really showstopper when using wayland. I would like to help technically, is there any pointer where to start? Thanks
Unfortunately, there is no general way to do this on wayland. In fact, it's worse that than. You would need to add support on each wayland compositor, i.e. not gonna happen.
If you are only using a specific compositor though, you could perhaps open a feature request there for the functionality that xcape provides.
So, I'm kinda confused, just moved to wayland and some applications will not work with xcape (gnome-terminal) but some do (emacs, xterm).
Is anyone able to explain why it doesn't work? does anyone know what's happening behind the scenes?
Emacs and XTerm do not support Wayland protocol. They are displayed via XWayland as regular Xorg apps therefore xcape works with them. On the other hand, Gnome-Terminal (thanks to GTK) is a native Wayland application and this is why xcape is not usable with it.
If you're using GNOME or GDM specifically, you can tell it to launch a regular X session instead of Wayland by following the Arch wiki until this is added.
Take a look at caps2esc which works at the device layer rather than the windowing system: https://github.com/oblitum/caps2esc
I haven't used it myself (xcape is working great for me) but it should work with Wayland. Looking at the issues, it appears that it can have some unintended side-effects, so YMMV.
I just want to point out that caps2esc has been moved to GitLab: https://gitlab.com/interception/linux/plugins/caps2esc xcape was the last thing keeping me from using Wayland (on machines that I don't need remote desktop), and caps2esc has been working well for me in Wayland GNOME so far. caps2esc has also been refactored with the main code split out into an interception-tools package which with some work can allow for even more complex keyboard behavior.
i've also hacked something together that works on wayland. it uses evdev, uinput and udev.
https://github.com/wbolster/evcape
warning: this is not mature software!
I've also hacked something together with evdev/uinput: evscript. Instead of just doing the xcape thing, it's scriptable! You can do other fancy input mapping things with it :)
Unfortunately, there is no general way to do this on wayland. In fact, it's worse that than. You would need to add support on each wayland compositor, i.e. not gonna happen.
One thing that has changed now is the existence of wlroots and multiple compositors using it. If you built upon wlroots you may be able to get something that works more generally across multiple wayland compositors.
The last three suggestions above (caps2esc, evcape, evscript) all work at the device layer through evdev which is below Wayland and so they all already work on X, on Wayland, or even in a plain terminal without a graphical environment. From my research several years ago, Mutter and Kwin don't provide a plugin system to allow something like xcape to work, so a wlroots solution wouldn't be as universal as the evdev ones. Still, if wlroots provided an extension system that was user accessible, that could be preferrable on wlroots systems. The evdev solutions all require root which users do not always have access to. Also, it is a little scary using them because if you screw things up you could lock yourself out of being able to access your system via keyboard input.
Note there was some interest in an xcape feature in sway but I don't understand the resolution. That issue was closed with the recommendation to use custom keymaps, but in the linked issue there is still a bounty listed for adding xcape functionality.
wlroots is a library for building compositors — it does not expose anything directly to users of these compositors.
I use Wayfire, and I made this plugin for it now.
Just noticed this discussion and thought I'd chime in: While I'm currently using xcape, at-home-modifier used to work great for me for years and it's based on evdev. So I assume it should also work on Wayland.
I want to tune in and say that theres a better alternative to caps2esc called dual-function-keys https://gitlab.com/interception/linux/plugins/dual-function-keys/
It allows for more extensive customization. From capslock being control and escape to space-cadet and more. There is also configuration per keyboard. Example of it here: https://gitlab.com/interception/linux/plugins/dual-function-keys/-/blob/master/doc/examples.md#complete-example-thanks-heymajor-
As others have stated, https://gitlab.com/interception/linux/plugins/caps2esc is a good replacement. Here are the steps that I used to get it configured on Debian. Works with both Wayland and Xorg on Debian GNU/Linux 12 (bookworm).
Install requirements:
sudo apt install interception-caps2esc interception-tools-compat
Create /etc/interception/udevmon.d/caps2esc.yaml with the contents suggested at https://gitlab.com/interception/linux/plugins/caps2esc#execution.
Restart the service:
sudo systemctl restart udevmon
Edit: Unfortunately, the above config does not work in combination with mouse events such as Ctrl+click or Ctrl+scroll. The caps2esc and interception-tools READMEs have some examples on how to configure this, but I wasn't able to figure out how to make it work on my computer.
