wlr-protocols
wlr-protocols copied to clipboard
swaywm
Add wlr-keyboard-modifiers-unstable protocol
I think I'm still -1 on this protocol tbh.
Do you have any suggestions to improve it? Any other way to get modifiers then?
I'd just like to add my support for this as a user. I constantly switch between three languages that require distinct layouts, and it's super helpful to have my status bar display the current one. I get that this protocol might seem too specific, but I feel like it addresses an important point. Thanks @harishkrupo for putting in the work for this, and @emersion and @ddevault for giving feedback and guidance!
As a DE dev, I would also like to vouch for the usefulness of this protocol.
the protocol should probably be extended to get all the configured layouts (so that you can have a pop-up menu with all the layouts), and also to switch to another layout.
I'd just like to add my support for this as a user. I constantly switch between three languages that require distinct layouts, and it's super helpful to have my status bar display the current one. I get that this protocol might seem too specific, but I feel like it addresses an important point. Thanks @harishkrupo for putting in the work for this, and @emersion and @ddevault for giving feedback and guidance!
afaict this protocol does not fulfill this use-case. But you can fulfill this use-case anyway by just listening for keymaps on wl_seat, right?
afaict this protocol does not fulfill this use-case. But you can fulfill this use-case anyway by just listening for keymaps on
wl_seat, right?
@ddevault, Does wl_seat advertise keymaps? I don't see any event for that here: https://gitlab.freedesktop.org/wayland/wayland/blob/master/protocol/wayland.xml#L1663
I think that this protocol needs to be extended to be also able to switch the current layout (and possibly enumerate all layouts, if there is no other way to do that).
But you can fulfill this use-case anyway by just listening for keymaps on wl_seat, right?
No, because when you switch the layout, the keymap doesn't change (it contains multiple layouts). Instead, the modifiers change. We do send modifiers, but only to the currently keyboard-focused surface. So bars aren't notified.
Does wl_seat advertise keymaps?
See wl_keyboard.keymap.
I think that this protocol needs to be extended to be also able to switch the current layout (and possibly enumerate all layouts, if there is no other way to do that).
Is it possible at all to programatically switch layouts using the libxkbcommon API? EDIT: seems like it, since you know the number of layouts and you can set modifiers.
Enumerating all layouts is possible client-side using the libxkbcommon API. It gives names like English (US) though, not things like en.
Oh, and this protocol should include a keymap event too, since there's no guarantee it's sent to unfocused clients in the protocol.
Enumerating all layouts is possible client-side using the libxkbcommon API. It gives names like English (US) though, not things like en.
https://github.com/xkbcommon/libxkbcommon/issues/22 people suggested parsing evdev.xml (part of xkeyboard-config)
people suggested parsing evdev.xml (part of xkeyboard-config)
All right. In any case, it doesn't belong to this protocol, and should be done client-side.
Does the xkb state sent by the compositor also contain the list of enabled layouts?
Does the xkb state sent by the compositor also contain the list of enabled layouts?
Yes.
Extending this a bit: what if a client (bar or shell) wants to listen to e.g. KEY_VOLUMEDOWN, KEY_VOLUMEUP or KEY_POWER. If we want to allow clients to handle this we might need a protocol to send certain input events to special clients (maybe using a whitelist in the compositor so clients can request certain input events but only get access to them if whitelisted).
Extending this a bit: what if a client (bar or shell) wants to listen to e.g. KEY_VOLUMEDOWN, KEY_VOLUMEUP or KEY_POWER. If we want to allow clients to handle this we might need a protocol to send certain input events to special clients (maybe using a whitelist in the compositor so clients can request certain input events but only get access to them if whitelisted).
Related: https://patchwork.freedesktop.org/patch/172113/
Note that in sway, we handle this by running commands instead of having some kind of "keybind protocol".
wlr-protocols has migrated to gitlab.freedesktop.org. This pull request has been moved to:
https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/31