render

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

@@ -233,47 +233,60 @@ hopefully. I have not yet read the implementation in XWayland though…</p>
 <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>
+<a class="reference external" href="TODO">wl_keyboard::modifiers</a> events containing the required data. To prove
+our hypotheses we can use <tt class="docutils literal">wev</tt> which does very little post-processing as
+with <tt class="docutils literal">xev</tt>.</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>
+data, but <tt class="docutils literal">xkb_v1</tt>-style keycodes are probably close (they are off by 8,
+which is kind of expected).</p>
+<p>While exploring what happens I found out there is a bug in the stable version
+1.0.0 of <tt class="docutils literal">wev</tt>, where it forgets to include the serial number for
+wl_keyboard::modifiers. It has already <a class="reference external" href="https://git.sr.ht/~sircmpwn/wev/commit/83de8e931ab04ce3322a58b359d8effa7901b21c">been patched</a>
+15 months ago, but the patch is not included in a release yet.</p>
 <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>
+started writing one</a>
+<a class="footnote-reference" href="#wiresharkify" id="footnote-reference-1">[1]</a>. Only then I learned that I can set the environment variable
+<tt class="docutils literal">WAYLAND_DEBUG=1</tt> 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 <a class="reference external" href="TODO">building guide</a>. Even the <a class="reference external" href="TODO">debugging extras page</a> does
+not mention this.)</p>
+<!-- should fix the wl docs instead of ranting, though… -->
+<p>By running <tt class="docutils literal">WAYLAND_DEBUG=1 Xwayland :15</tt> and <tt class="docutils literal"><span class="pre">DISPLAY=:15</span> xev</tt>, we do
+learn what we thought was happening:</p>
+<ul class="simple">
+<li>XWayland gets XKB v1 keymap (I trust sway to supply the same map as to
+<tt class="docutils literal">wev</tt> earlier.)</li>
+<li>XWayland gets the correct (Wayland core) events from the compositor</li>
+<li>XWayland sends a wrong (X11 with XKB) events to <tt class="docutils literal">xev</tt>.</li>
+</ul>
+<p>This confirms that XWayland is really the culprit here.</p>
+</div>
+</div>
+<div class="section" id="digging-into-xwayland">
+<h2>Digging into XWayland</h2>
+<p>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 <tt class="docutils literal">grep <span class="pre">-r</span>
+wl_keyboard src/</tt> tells us that the keyboard handling occurs in the file
+<tt class="docutils literal"><span class="pre">hw/xwayland/xwayland-input.c</span></tt> in functions <tt class="docutils literal">keyboard_handle_*</tt>, which look
+like the libwayland-client handlers we have seen in <tt class="docutils literal">wev</tt>.</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>
+<hr class="docutils" />
+<table class="docutils footnote" frame="void" id="wiresharkify" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#footnote-reference-1">[1]</a></td><td>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.</td></tr>
+</tbody>
+</table>
 </div>
 
 	</div>