|
|
||
|---|---|---|
| src | ||
| .gitignore | ||
| build.zig | ||
| build.zig.zon | ||
| LICENSE | ||
| README.md | ||
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_compatsections 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.
includestatements 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.