|
|
|
@ -196,15 +196,81 @@ code <TODO>`__ :-/ (Actually, XWayland might not process key events itself, inst
|
|
|
|
just passing them to clients, but this seems inconsistent with the issue – what
|
|
|
|
just passing them to clients, but this seems inconsistent with the issue – what
|
|
|
|
else would be introducing the second group switch?)
|
|
|
|
else would be introducing the second group switch?)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
So now I need to understand a (hopefully small) parts of two protocols: X11 to
|
|
|
|
.. understanding xev, XKeyEvents &c.
|
|
|
|
understand what the X11 clients receive from XWayland, and Wayland to
|
|
|
|
.. Note: neither xev is very barebones and does very little postprocessing of
|
|
|
|
understand what XWayland gets from my compositor.
|
|
|
|
events. (naturally.)
|
|
|
|
|
|
|
|
.. X11: state: 0x2000, sway: 0x4000 or 0x0. These state bits are *not*
|
|
|
|
Understanding X11
|
|
|
|
mentioned in libX11 docs… (bits 13 and 14)
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
<https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Computing_A_State_Field_from_an_XKB_State>`__
|
|
|
|
|
|
|
|
of `the XKB extension documentation
|
|
|
|
|
|
|
|
<https://www.x.org/releases/current/doc/kbproto/xkbproto.html>`__.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 <TODO>`__, `wl_keyboard::key <TODO>`__ and
|
|
|
|
|
|
|
|
`wl_keyboard::modifiers <TODO>`__ 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 <TODO>`__ 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 <https://gitea.ledoian.cz/LEdoian/sopass/>`__
|
|
|
|
|
|
|
|
|
|
|
|
.. TO-MENTION:
|
|
|
|
.. TO-MENTION:
|
|
|
|
- nested compositor issues
|
|
|
|
- nested compositor issues
|
|
|
|
- the IM resolves compose? (I could bisect it, but too lazy)
|
|
|
|
- the IM resolves compose? (I could bisect it, but too lazy)
|
|
|
|
- copy my issue comment in case link rots.
|
|
|
|
- copy my issue comment in case link rots.
|
|
|
|
- list of all the packages I had downloaded and compiled
|
|
|
|
- list of all the packages I had downloaded and compiled
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. TODO: rename XWayland to Xwayland…
|
|
|
|
|
