This part is supposed to also be simple: the core Wayland protocol will send us wl_keyboard::keymap, wl_keyboard::key and -wl_keyboard::modifiers events containing the required data.
+wl_keyboard::modifiers events containing the required data. To prove +our hypotheses we can use wev which does very little post-processing as +with xev.The client does not seem to have a say in what kind of keymap it will get, it is up to the compositor. This means that even XWayland cannot say it wants raw -data, but xkb_v1-style keycodes are probably close.
-While exploring what happens I found a bug in wev (as of version 1.0.0-13 -in Arch): for wl_keyboard::modifiers the group is reported as the serial -number:
--[14: wl_keyboard] key: serial: 238464; time: 554528472; key: 66; state: 1 (pressed) - sym: Mode_switch (65406), utf8: '' -[14: wl_keyboard] modifiers: serial: 1; group: 0 - depressed: 00000000 - latched: 00000000 - locked: 00000000 --
Apparently I am fixing more than one project :-)
-Note: Currently, SourceHut is down (TODO: remove this when sr.ht is up), so I -cannot link you to my patch, so here it is instead:
-
---- wev.c.orig 2024-01-13 22:38:03.739239211 +0100
-+++ wev.c 2024-01-13 22:38:08.012465335 +0100
-@@ -368,7 +368,7 @@
- uint32_t mods_locked, uint32_t group) {
- struct wev_state *state = data;
- int n = proxy_log(state, (struct wl_proxy *)wl_keyboard, "modifiers",
-- "serial: %d; group: %d\n", group);
-+ "serial: %d; group: %d\n", serial, group);
- if (n != 0) {
- printf(SPACER "depressed: %08X", mods_depressed);
- print_modifiers(state, mods_depressed);
-
+data, but xkb_v1-style keycodes are probably close (they are off by 8,
+which is kind of expected).
+While exploring what happens I found out there is a bug in the stable version +1.0.0 of wev, where it forgets to include the serial number for +wl_keyboard::modifiers. It has already been patched +15 months ago, but the patch is not included in a release yet.
But I am also interested in what is exchanged between the compositor and XWayland server. And there does not seem to be any kind of sniffer yet, so I -started writing one
+started writing one +[1]. Only then I learned that I can set the environment variable +WAYLAND_DEBUG=1 to get dumps of all the calls that are happening. (To my +defense, this does not seem to be very documented. I only found a small note in +the building guide. Even the debugging extras page does +not mention this.) + +By running WAYLAND_DEBUG=1 Xwayland :15 and DISPLAY=:15 xev, we do +learn what we thought was happening:
+This confirms that XWayland is really the culprit here.
+ + +At this point, we have all the tools, references to documentation and knowledge +we could possibly have, so now we get our hands dirty. A simple grep -r +wl_keyboard src/ tells us that the keyboard handling occurs in the file +hw/xwayland/xwayland-input.c in functions keyboard_handle_*, which look +like the libwayland-client handlers we have seen in wev.
-| [1] | It would be nice if we could analyse the traffic in a +general packet analysis program like Wireshark, though, so I might return to +sopass and write the dissectors and dumping from sopass to a pcap file in a +future. However, this gets put on hold now. |