From ce07b83635c4f802129502ec28feaecca9359afd Mon Sep 17 00:00:00 2001 From: Pavel 'LEdoian' Turinsky Date: Sat, 13 Jan 2024 22:54:27 +0100 Subject: [PATCH] render --- output/drafts/ucw-keymap-on-wayland.html | 66 ++++++++++++++++++++++-- 1 file changed, 61 insertions(+), 5 deletions(-) diff --git a/output/drafts/ucw-keymap-on-wayland.html b/output/drafts/ucw-keymap-on-wayland.html index e7a059c..9d686eb 100644 --- a/output/drafts/ucw-keymap-on-wayland.html +++ b/output/drafts/ucw-keymap-on-wayland.html @@ -208,16 +208,72 @@ version of (Xorg-style) xkb, which might mean I will be dealing with +

Understanding X11

+

This part is maybe the easier one, because xev pretty much dumps the data. +I should check in the server code as well, but for the Czech chords xev +seems to receive KeyEvents with state 0x2000 under Xorg (i3wm) and with +0x4000 under XWayland when three groups are set up (for two groups the +state is 0x0, i.e. the same as for English keypresses). State bits this +high encode the active group and are described in the relevant part +of the XKB extension documentation.

+

We can see that if we set the GroupsWrap control of XKB (I don't know +where/how yet) to ClampIntoRange 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.

+ +

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…

+ +
+

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.

+

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);
+
+

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

+ +