|
|
|
|
@ -229,43 +229,50 @@ 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.
|
|
|
|
|
`wl_keyboard::modifiers <TODO>`__ 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 <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);
|
|
|
|
|
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
|
|
|
|
|
<https://git.sr.ht/~sircmpwn/wev/commit/83de8e931ab04ce3322a58b359d8effa7901b21c>`__
|
|
|
|
|
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 <https://gitea.ledoian.cz/LEdoian/sopass/>`__
|
|
|
|
|
[#wiresharkify]_. 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 <TODO>`__. Even the `debugging extras page <TODO>`__ does
|
|
|
|
|
not mention this.)
|
|
|
|
|
|
|
|
|
|
.. should fix the wl docs instead of ranting, though…
|
|
|
|
|
|
|
|
|
|
By running ``WAYLAND_DEBUG=1 Xwayland :15`` and ``DISPLAY=:15 xev``, we do
|
|
|
|
|
learn what we thought was happening:
|
|
|
|
|
|
|
|
|
|
- XWayland gets XKB v1 keymap (I trust sway to supply the same map as to
|
|
|
|
|
``wev`` earlier.)
|
|
|
|
|
- XWayland gets the correct (Wayland core) events from the compositor
|
|
|
|
|
- XWayland sends a wrong (X11 with XKB) events to ``xev``.
|
|
|
|
|
|
|
|
|
|
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``.
|
|
|
|
|
|
|
|
|
|
.. TO-MENTION:
|
|
|
|
|
- nested compositor issues
|
|
|
|
|
@ -274,3 +281,10 @@ started writing one <https://gitea.ledoian.cz/LEdoian/sopass/>`__
|
|
|
|
|
- list of all the packages I had downloaded and compiled
|
|
|
|
|
|
|
|
|
|
.. TODO: rename XWayland to Xwayland…
|
|
|
|
|
|
|
|
|
|
---------
|
|
|
|
|
|
|
|
|
|
.. [#wiresharkify] 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.
|
|
|
|
|
|
