From 2133e2ffe1c09260264b0de0f8ac760ab9958801 Mon Sep 17 00:00:00 2001 From: Pavel 'LEdoian' Turinsky Date: Sat, 13 Jan 2024 22:53:36 +0100 Subject: [PATCH] =?UTF-8?q?UCW=20vs.=20XKB:=20more=20knowledge=E2=80=A6?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ucw-keymap-on-xwayland.rst | 78 +++++++++++++++++++++++++++--- 1 file changed, 72 insertions(+), 6 deletions(-) diff --git a/content/ucw-keymap-on-xwayland.rst b/content/ucw-keymap-on-xwayland.rst index 75cdbe9..7a0772d 100644 --- a/content/ucw-keymap-on-xwayland.rst +++ b/content/ucw-keymap-on-xwayland.rst @@ -196,15 +196,81 @@ code `__ :-/ (Actually, XWayland might not process key events itself, inst just passing them to clients, but this seems inconsistent with the issue – what else would be introducing the second group switch?) - -.. understanding xev, XKeyEvents &c. -.. Note: neither xev is very barebones and does very little postprocessing of - events. (naturally.) -.. X11: state: 0x2000, sway: 0x4000 or 0x0. These state bits are *not* - mentioned in libX11 docs… (bits 13 and 14) +So now I need to understand a (hopefully small) parts of two protocols: X11 to +understand what the X11 clients receive from XWayland, and Wayland to +understand what XWayland gets from my compositor. + +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. + +.. Read also xkbproto: Server Internal Modifiers and Ignore Locks Behavior (might explain sth?) + +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 `__ .. 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…