wvkbd: falling back to uinput device when zwp-virtual-keyboard-manager-v1 is unavailable

Wvkbd is currently only usable on compositors that support the zwp-virtual-keyboard-manager-v1 protocol. Some major compositors don't# implement this at the moment, notably KDE's KWin (where there's an inactive ticket where this has been mentioned: https://invent.kde.org/plasma/kwin/-/issues/74#note_369963) as well as GNOME, where this isn't even planned.

Thus I believe it would be very useful for users of such compositors if wvkbd could fall back to creating a fake input device using Linux's uinput feature if the protocol isn't implemented. Given that the uinput API also uses linux keycodes, this would be reasonably easy to implement.


Assigned to
9 months ago
9 months ago
No labels applied.

~stacyharper 9 months ago


I'm against this approach. One of Wayland goal is to offer alternatives to avoid this. Openning /dev/uinput permission to the users is basically openning a breach to the user security, cause it make easy to keylog inputs.

Most distro still have to do this, for some programs (aka Steam, aka dotool, etc), but we should all work to close this breach.

In that specific situation, wvkbd is a Wayland program that have a limited scopes as a virtual keyboard, and the protocol fits nicely.

I would prefer to work, and implement zwp-virtual-keyboard-manager-v1 in KWin, than to fallback to uinput :)


~aren 9 months ago

Is it possible to start wvkbd with any compositors that don't support the zwp-virtual-keyboard protocol? I'd expect the more limiting thing would be that wvkbd requires the wlr-layer-shell protocol.

I could see a case for making wvkbd more modular, it might be useful to be able to embed it in a lock screen (perhaps using a stripped down wayland-like protocol?).

Imo the best long term solution would be if the wayland folks could agree on a protocol for virtual keyboards (perhaps we should try to nudge them?), so we could support one way of doing things that works everywhere.

~lordmzte 9 months ago

I completely agree that this is not a clean solution at all, however the situation for KWin is unclear, and for GNOME, it's already been decided that zwp-virtual-keyboard-manager-v1 will not be implemented. I think they believe it's not a good protocol because it emulates a real keyboard (which I believe is it's advantage). These compositors do actually already support virtual keyboard through the zwp-input-method-v2 protocol. This protocol allows inserting text in a text field and such and doesn't actually handle key events. What the developers of compositors that implement only this protocol usually fail to consider is that this protocol only works in well-written Wayland apps (those which report text input, this cannot work on XWayland apps for example) and also doesn't support modifier keys, so this is also unsuited for terminals. It also can't be brought up on command and will only react to text inputs.

Register here or Log in to comment, or comment via email.