@rbernon Thanks for working on this! The code looks better/simpler than the experimental branch code (and WineX11).
Concerning `xkbregistry`, it is present in `xkbcommon >= 1.0.0`. On the one hand, making it mandatory would preclude distros that are still in use/supported, like Debian 10 and Ubuntu 20.04. On the other hand, these older distro versions are not likely to have good Wayland support in the various compositors, so perhaps not supporting them is not a big loss? I guess if it is straightforward to make this optional, that's a way forward for the short-term, and we can revisit the decision at a later point. A related upstream issue which hasn't seen much traction is: https://gitlab.freedesktop.org/wayland/wayland/-/issues/273.
I haven't yet looked at the code in more detail yet (should I, or is the branch not at that point yet?), but here some first observations and test results with this branch (other than the points below, this branch works well for me):
1. On GNOME the first keyboard layout is always used (even if it's not the active one) when first creating a window. After investigating a bit, this turns out this is a bug in GNOME, since it violates the spec and does not send `keyboard.modifiers` after `keyboard.enter` as it should (it sends `modifiers` before `enter`). This is already known upstream, and I'll try to move the fix forward on the GNOME side.
In the meantime, the workaround on our side could be to not check the focus when handling `modifiers`. This is not ideal, but the intention (which is not clearly stated in the spec), is that only focused surfaces should be getting `modifiers` events, so by getting that event the implication is that the surface has the focus (or in this case it will soon have it). I think it would work out since the only thing we won't be able to do is send `WM_INPUTLANGCHANGEREQUEST`, which we will send in the upcoming `enter` event.
2. The behavior of composing is different compared to native Wayland apps and winex11 (native X11). In particular:
Same behavior: * `´ + α` (valid next key) = winex11/native wayland: `ά` this: `ά`
Different behavior: * `´ (waiting for next key)` = winex11/native wayland: `´` this: `(nothing)` * `´ + π` (invalid next key) = winex11/native wayland: `´π` this: `π` * `´ + <backspace>` = winex11/native wayland: `deletes just added ´` this: `deletes previous character`
Not sure what's the correct/expected behavior here or if it matters.
3. Using Alt+Shift to switch layouts in GNOME leaves the window in a state where nothing can be typed, and we get stuck with a repetition of `WM_SYSKEYDOWN` for Alt. It turns out that when changing layouts, GNOME temporarily switches away the focus away from the surface (presumably to the language switcher HUD widget), and we get a leave and reenter of the Wine window, without getting a key up event. This is fine, since according to the `wl_keyboard.leave` spec:
After this event client must assume that all keys, including modifiers, are lifted and also it must stop key repeating if there's some going on.
The current version is not clearing the key/repeat state on leave, and I think that's the reason we get stuck with the Alt key repeats and broken state.
4. Some layouts (e.g., colemak) change the effect of Caps Lock to become only `<Backspace>`. This branch seems to apply both effects, so `a<Caps>a` results in `A` instead of `a`.