About Wayland support

[suxpert]

The original vimcaps was developed for Windows and later added support for X11. Nowadays, most Linux distributions have started using Wayland as the default display server, and some have even removed X11 support entirely.

Unfortunately, Wayland's design philosophy --- emphasizing security, privacy, and isolation --- intentionally does not provide global keyboard emulation or input simulation APIs that work across all Wayland compositors, unlike for X11.

To implement the auto toggle capslock feature on Wayland, we likely need to support different desktop environments (compositors) individually, because each may expose its own (non‑standard) method for virtual input.

Some candicates:

• virtual-keyboard-unstable-v1: used by wtype, seems to work on wlroot-based compositor, but not on KDE Plasma or GNOME;
• libei: need more information. I got this:

Modifiers in are handled by obtaining the modifier mask from the X server, identifying any difference to the intended mask and emulating key events to change the modifier state to the intended one. For example, if capslock is on, xdotool would send a capslock key event first (thus disabling capslock) and then the actual key sequence. This is followed by another capslock key event to restore the modifier mask. xdotool

This is not possible for a pure libei client as the modifier state is maintained by the windowing system (if any). A client can obtain the modifier state on Wayland on but when the client is in-focus, there is rarely a need to emulate events. wl_keyboard.enter

• For Plasma and GNOME, perhaps finding the corresponding DBus interface is helpful.

A universal, privilege‑free, cross‑compositor solution does not currently exist for this specific use case.
Any insights or contributed backends are welcome.