pop-os
WIP Add `cosmic-keymap-unstable-v1` protocol
Includes example client using cosmic-client-toolkit.
https://github.com/pop-os/cosmic-applets/tree/master/cosmic-applet-input-sources sets the keyboard layout by modifying xkb_config. But it should instead leave the keymap unchanged, and change the group. The applet also doesn't recognize when the group is changed by something else.
KDE has a DBus protocol for this (https://invent.kde.org/plasma/plasma-workspace/-/blob/master/components/keyboardlayout/org.kde.KeyboardLayouts.xml?ref_type=heads). We could have one, but a Wayland protocol is easier to integrate into the compositor, and lets us just use wl_keyboard.keymap to get the current keymap and list of layouts. And privileged Wayland protocols match how our applets typically work.
Zbus is however a bit less verbose that adding a wayland protocol.... something we should work on (https://github.com/Smithay/smithay/pull/1327, etc.).
I guess this will also need an event for the active group, since modifiers (unlike keymap) is only being sent to focused windows).
A protocol to notify a client using it about group modifier changes regardless of focus should allow for a simple keyboard layout indicator. The question becomes how much the protocol should support outside of that single event, e.g. should it allow the client to set a new global group modifier or not.
The keyboard keymap_format and keymap events may be sent when calling wl_seat.get_keyboard() from what I remember but I think its not actually defined in the protocol. So it might make sense to ensure in the new protocol that the client has bound the keyboard and received the keymap event before starting to listen for the group modifier.
So it might make sense to ensure in the new protocol that the client has bound the keyboard and received the keymap event before starting to listen for the group modifier.
Right, I think an extension object for a wl_keyboard makes the most sense here, to make sure the client has actually bound a wl_keyboard. Something like zcosmic_keymap_manager_v1::get_keyboard_listener returning a zcosmic_keyboard_listener which has the necessary events.
Yeah. I was thinking an extension object would be unnecessary if we just have a request to set the group and not any events. But I guess we need notification of the current group as well, so an extension object makes sense.
(Still annoying the extra boilerplate that adds with wayland-rs... Need to find a better way to manage that.)
We may need to revisit how this works in the future when we properly integrate input methods, but I guess that can be left out for now. I need to look more into how that works on Gnome, etc.
This looks great. Do you intend to propose it upstream as well? In either case labwc will consider adding support for it. Some way for an external application like a panel to show and set the current layout is one of the missing pieces and gets mentioned fairly often.
FWIW, KWin has an alternative mode where it just responds to locale1 settings too. Fedora KDE uses this for the live session. And COSMIC has this capability too (since it was implemented in https://github.com/pop-os/cosmic-settings-daemon/pull/35). So what is this protocol for now?
So what is this protocol for now?
Compositors that don't want to depend on dbus for basic functionality. Additionally, at least from a quick glance of the linked PR the dbus interface appears to set the whole xkb config rather than just changing the group modifier.
D-Bus is required for basic functionality already. It's been that way for (conservatively) at least 15 years.
Maybe keymap isn't the best term for this protocol, but I don't know what is. (cosmic-keymap-group? cosmic-keyboard-group?).
It simply provides the group number currently active in the keymap (which is exposed by wl_keyboard::keymap) and a way to set it. So together it's possible to show a list of keyboard layouts, and select one.
I don't believe locale1 does anything like that, or would be intended to. That defines what keymap to use (with one or more groups).
Do you intend to propose it upstream as well?
Yeah, it seems like it could be reasonable to propose upstream, and I was thinking of doing so. It's a fairly clean and simple protocol if there aren't concerns about how it works. If labwc is interested I guess that's additional reason to.
Maybe cosmic-keymap-layout would work? (libxkb uses xkb_layout_index_t and xkb_keymap_layout_get_name() )
Using an IME, on Gnome or on compositor supporting input-method-unstable-v2, doesn't seem to impact the wl_keyboard::keymap, as expected. So any input method layouts would need to be listed separately, alongside the non-IME inputs. If it were integrated similarly to Gnome.
Though I wonder if https://wayland.app/protocols/virtual-keyboard-unstable-v1#zwp_virtual_keyboard_v1:request:keymap could mess with how this protocol assumes wl_keyboard::keymap will work. Fcitx5 and Ibus use that, but just send the same keymap they got from https://wayland.app/protocols/input-method-unstable-v2#zwp_input_method_keyboard_grab_v2. Hopefully version 3 of the input method protocol will make it not require the virtual keyboard protocol, but if that protocol still exists and may be arbitrarily changing our keymap, that may not work well for an applet trying to list layouts using wl_keyboard::keymap.
It looks like KWin implements an org.kde.KeyboardLayouts DBus protocol for this functionality. So I guess the behavior there can be compared. As far as how this interacts with IMEs, etc.
I guess the concern I listed earlier about keymap doesn't happen on KDE with org.kde.KeyboardLayouts, since KDE is using input-method-v1. Which lets the input method send keysyms, instead of keycodes. Different from how the virtual-keyboard protocol works.
KDE's applet also doesn't seem to interact with the layout active in the IME engine in any way. I guess the assumption is that the fcitx5 app indicator will be used instead.