diff --git a/content/ucw-keymap-on-xwayland.rst b/content/ucw-keymap-on-xwayland.rst index 7a0772d..69ea70a 100644 --- a/content/ucw-keymap-on-xwayland.rst +++ b/content/ucw-keymap-on-xwayland.rst @@ -229,43 +229,50 @@ Understanding Wayland 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 `__ +[#wiresharkify]_. 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.) + +.. should fix the wl docs instead of ranting, though… + +By running ``WAYLAND_DEBUG=1 Xwayland :15`` and ``DISPLAY=:15 xev``, we do +learn what we thought was happening: + +- XWayland gets XKB v1 keymap (I trust sway to supply the same map as to + ``wev`` earlier.) +- XWayland gets the correct (Wayland core) events from the compositor +- XWayland sends a wrong (X11 with XKB) events to ``xev``. + +This confirms that XWayland is really the culprit here. + +Digging into XWayland +===================== + +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``. .. TO-MENTION: - nested compositor issues @@ -274,3 +281,10 @@ started writing one `__ - list of all the packages I had downloaded and compiled .. TODO: rename XWayland to Xwayland… + +--------- + +.. [#wiresharkify] 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.