UCW vs. XKB: We know everything :-)

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 <TODO>`__, `wl_keyboard::key <TODO>`__ and
-`wl_keyboard::modifiers <TODO>`__ events containing the required data.
+`wl_keyboard::modifiers <TODO>`__ 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.
+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 a bug in ``wev`` (as of version 1.0.0-13
+
-in Arch): for wl_keyboard::modifiers the group is reported as the serial
+While exploring what happens I found out there is a bug in the stable version
-number::
+1.0.0 of ``wev``, where it forgets to include the serial number for
-
+wl_keyboard::modifiers. It has already `been patched
-    [14:     wl_keyboard] key: serial: 238464; time: 554528472; key: 66; state: 1 (pressed)
+<https://git.sr.ht/~sircmpwn/wev/commit/83de8e931ab04ce3322a58b359d8effa7901b21c>`__
-                          sym: Mode_switch  (65406), utf8: ''
+15 months ago, but the patch is not included in a release yet.
-    [14:     wl_keyboard] modifiers: serial: 1; group: 0
-                          depressed: 00000000
-                          latched: 00000000
-                          locked: 00000000
-
-Apparently I am `fixing <TODO>`__ 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);
 
 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 <https://gitea.ledoian.cz/LEdoian/sopass/>`__
+[#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 <TODO>`__. Even the `debugging extras page <TODO>`__ 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 <https://gitea.ledoian.cz/LEdoian/sopass/>`__
   - 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.