render

output/drafts/ucw-keymap-on-wayland.html

@@ -208,16 +208,72 @@ version of (Xorg-style) xkb, which might mean I will be dealing with <a class="r
 code</a> :-/ (Actually, XWayland might not process key events itself, instead
 just passing them to clients, but this seems inconsistent with the issue – what
 else would be introducing the second group switch?)</p>
-<!-- understanding xev, XKeyEvents &c. -->
+<p>So now I need to understand a (hopefully small) parts of two protocols: X11 to
-<!-- Note: neither xev is very barebones and does very little postprocessing of
+understand what the X11 clients receive from XWayland, and Wayland to
-events. (naturally.) -->
+understand what XWayland gets from my compositor.</p>
-<!-- X11: state: 0x2000, sway: 0x4000 or 0x0. These state bits are *not*
+<div class="section" id="understanding-x11">
-mentioned in libX11 docs… (bits 13 and 14) -->
+<h3>Understanding X11</h3>
+<p>This part is maybe the easier one, because <tt class="docutils literal">xev</tt> pretty much dumps the data.
+I should check in the server code as well, but for the Czech chords <tt class="docutils literal">xev</tt>
+seems to receive <tt class="docutils literal">KeyEvents</tt> with state <tt class="docutils literal">0x2000</tt> under Xorg (i3wm) and with
+<tt class="docutils literal">0x4000</tt> under XWayland when three groups are set up (for two groups the
+state is <tt class="docutils literal">0x0</tt>, i.e. the same as for English keypresses). State bits this
+high encode the active group and are described in <a class="reference external" href="https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Computing_A_State_Field_from_an_XKB_State">the relevant part</a>
+of <a class="reference external" href="https://www.x.org/releases/current/doc/kbproto/xkbproto.html">the XKB extension documentation</a>.</p>
+<p>We can see that if we set the <tt class="docutils literal">GroupsWrap</tt> control of XKB (I don't know
+where/how yet) to <tt class="docutils literal">ClampIntoRange</tt> it should also help work around the
+problem. But our goal is to align behaviour of XWayland and JustWayland, i.e.
+prevent XWayland seeing two group shifts, not to hack our way in either
+protocol, so we do not stop here.</p>
+<!-- Read also xkbproto: Server Internal Modifiers and Ignore Locks Behavior (might explain sth?) -->
+<p>At this point, I had an approximate idea of how XKB is supposed to do,
+hopefully. I have not yet read the implementation in XWayland though…</p>
+</div>
+<div class="section" id="understanding-wayland">
+<h3>Understanding Wayland</h3>
+<p>This part is supposed to also be simple: the core Wayland protocol will send us
+<a class="reference external" href="TODO">wl_keyboard::keymap</a>, <a class="reference external" href="TODO">wl_keyboard::key</a> and
+<a class="reference external" href="TODO">wl_keyboard::modifiers</a> events containing the required data.</p>
+<p>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 <tt class="docutils literal">xkb_v1</tt>-style keycodes are probably close.</p>
+<p>While exploring what happens I found a bug in <tt class="docutils literal">wev</tt> (as of version 1.0.0-13
+in Arch): for wl_keyboard::modifiers the group is reported as the serial
+number:</p>
+<pre class="literal-block">
+[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
+</pre>
+<p>Apparently I am <a class="reference external" href="TODO">fixing</a> more than one project :-)</p>
+<p>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:</p>
+<pre class="literal-block">
+--- wev.c.orig      2024-01-13 22:38:03.739239211 +0100
++++ wev.c   2024-01-13 22:38:08.012465335 +0100
+&#64;&#64; -368,7 +368,7 &#64;&#64;
+            uint32_t mods_locked, uint32_t group) {
+    struct wev_state *state = data;
+    int n = proxy_log(state, (struct wl_proxy *)wl_keyboard, &quot;modifiers&quot;,
+-                   &quot;serial: %d; group: %d\n&quot;, group);
++                   &quot;serial: %d; group: %d\n&quot;, serial, group);
+    if (n != 0) {
+            printf(SPACER &quot;depressed: %08X&quot;, mods_depressed);
+            print_modifiers(state, mods_depressed);
+</pre>
+<p>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 <a class="reference external" href="https://gitea.ledoian.cz/LEdoian/sopass/">I
+started writing one</a></p>
 <!-- TO-MENTION:
 - nested compositor issues
 - the IM resolves compose? (I could bisect it, but too lazy)
 - copy my issue comment in case link rots.
 - list of all the packages I had downloaded and compiled -->
+<!-- TODO: rename XWayland to Xwayland… -->
+</div>
 </div>
 
 	</div>