No description
Find a file
geemili 581636d483 initial commit: copy xkb module out of seizer
Also, add a build.zig, LICENSE, and README
2024-10-04 13:02:32 -06:00
src initial commit: copy xkb module out of seizer 2024-10-04 13:02:32 -06:00
.gitignore initial commit: copy xkb module out of seizer 2024-10-04 13:02:32 -06:00
build.zig initial commit: copy xkb module out of seizer 2024-10-04 13:02:32 -06:00
build.zig.zon initial commit: copy xkb module out of seizer 2024-10-04 13:02:32 -06:00
LICENSE initial commit: copy xkb module out of seizer 2024-10-04 13:02:32 -06:00
README.md initial commit: copy xkb module out of seizer 2024-10-04 13:02:32 -06:00

xkb_v1 keymap library

This library implements parsing xkb_v1 keymaps and then using said keymaps to translate keycodes into symbols.

At the moment it targets the use case of a Wayland client wanting to translate keycodes it has received from a Wayland compositor. As such, there are many features missing:

  • xkb_compat sections are parsed but ignored.
  • Modifier state transitions are not implemented, instead relying on compositors to send modifier updates.
  • Only a couple of key types are automatically detected, so more advanced key combinations may not work.
  • include statements are not implemented.

If you are looking for a full featured library, look at libxkbcommon. It is the library that this one is based on, and is the library the Wayland specification expects you to use.

Rant

The xkb_v1 format is designed as human readable configuration format. It implements a lot of features that make writing and maintaining a database of keyboard layouts easier. This is stuff that is relevant to the Wayland compositor.

On the flip side, Wayland clients are not really concerned with configuration. We don't receive the raw source code version of the xkb_v1 format, we receive a keymap that was fully parsed and assembled before being serialized and sent over to us. This serialized format (at least from what I've seen in practice) doesn't use most of xkb_v1's features.

Of course nothing in the protocol specification mandates using this serialization format. This is all the protocol specification has to say on the keymap format:

xkb_v1: libxkbcommon compatible, null-terminated string; to determine the xkb keycode, clients must add 8 to the key event keycode -- Wayland protocol | Wayland Explorer | wl_keyboard:keymap_format

As far as I'm concerned, this means that the Wayland protocol has a huge dependency on a specific implementation, at least if you want keyboard input. I don't understand why they went with this solution instead of something like sending both keycode and symbol events. It doesn't even save compositors a dependency because they have to understand the keycodes to do proper input multiplexing.

And if your response is "just use libxkbcommon", save me some time and put "load libxkbcommon from /lib/libxkbcommon.so" in the spec next time.