A few more insights into UCW layout

content/ucw-keymap-on-xwayland.rst

@@ -274,6 +274,65 @@ 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``.
 
+However, the fun ends here. I found the generic code of Xorg (which these
+handlers quickly call) rather hard to make sense of [#me-lost]_ (though ctags,
+``printf(3)``, debug build and gdb might help) and the implementation of XKB is
+rather massive: about 20 000 loc just in the ``xkb/`` directory. And touching
+this code in a bad way might break something somewhere for somebody.
+
+We can get creative though. We know that this issue is only present in
+XWayland, which (by a quick ``grep -l``) seems to live in ``hw/xwayland``. Yay,
+only about 12 000 loc to sift through :-) This code is safe(r) to destroy,
+though, since other stuff will supposedly not be influenced.
+
+This is about a month since I begun exploring the issue (I attend to this
+mostly on my commute or during free time in some evenings, so it goes slowly).
+Because of that, I became too fixated on a task of "getting ``xev`` not to show
+group 2 instead of group 1" (in the state bits). What I needed to remember was
+that my task could also be "getting XWayland's implementation of XKB group not
+interfere with the compositor's one".
+
+Can I have some fun, please? Imagine a `James Veitch's style of lines appearing here <TODO>`__… ::
+
+    static void
+    keyboard_handle_modifiers(void *data, struct wl_keyboard *keyboard,
+                              uint32_t serial, uint32_t mods_depressed,
+                              uint32_t mods_latched, uint32_t mods_locked,
+                              uint32_t group)
+    {
+        /*lol*/group = 0;
+        // the rest of function…
+
+Okay, ``xev`` tells me this is actually the way. Can I have more fun? ::
+
+        /*rofl*/return;
+
+.. Could we make the line above correctly indented?
+
+Oh yes I can! Even with this piece of heresy ``xev`` resolves state correctly,
+even with combination with other modifiers like control and shift, three
+groups, …
+
+This seems to be a sensible way, because the Wayland protocol seems to promise
+to send wl_keyboard::key before wl_keyboard::modifiers:
+
+    If this event [wl_keyboard::key] produces a change in modifiers, then the
+    resulting wl_keyboard.modifiers event must be sent after this event.
+
+My hypothesis is that XWayland's XKB updates its state when receiving the ::key
+events and the following ::modifiers event confuses it. However, I do not yet
+know what that code is supposed to do.
+
+.. TODO: test group changing/locking, not momentary.
+
+.. TODO: understand the reasoning behind the "dead" code
+
+
+
+
+
+
+
 .. TO-MENTION:
   - nested compositor issues
   - the IM resolves compose? (I could bisect it, but too lazy)
@@ -288,3 +347,14 @@ like the libwayland-client handlers we have seen in ``wev``.
    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.
+
+.. Before my browser crashes: https://rawgit.com/CoreSecurity/pcapy/master/pcapy.html https://libpcap.readthedocs.io/en/latest/
+   also, wireshark can import hexdumps
+
+.. [#me-lost] I tried to track how a wl_keyboard::key gets processed to a
+   KeyPress, but I ended up at it being processed in ``mieq``, where it gets
+   enqueued without group/state info and then it gets too generic. I have no
+   idea how XKB is tied into that, but I chickened out relatively quickly when
+   I realized that I should not really be touching the general code. I didn't
+   get to use gdb in the end, though I was very close to wanting to see
+   backtraces – I backed out just before trying this approach.