From d906a7cfee5f3163506e8dae143b3730ed196b30 Mon Sep 17 00:00:00 2001 From: Pavel 'LEdoian' Turinsky Date: Sun, 14 Jan 2024 21:29:02 +0100 Subject: [PATCH] render --- output/drafts/ucw-keymap-on-wayland.html | 75 ++++++++++++++---------- 1 file changed, 44 insertions(+), 31 deletions(-) diff --git a/output/drafts/ucw-keymap-on-wayland.html b/output/drafts/ucw-keymap-on-wayland.html index 9d686eb..3d7db8f 100644 --- a/output/drafts/ucw-keymap-on-wayland.html +++ b/output/drafts/ucw-keymap-on-wayland.html @@ -233,47 +233,60 @@ hopefully. I have not yet read the implementation in XWayland though…

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

+started writing one +[1]. 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.)

+ +

By running WAYLAND_DEBUG=1 Xwayland :15 and DISPLAY=:15 xev, we do +learn what we thought was happening:

+ +

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.

-
+
+ + + + + +
[1]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.