xkbcomp

Branch :

Log

Commit	Date	Message
939bf0e1	2025-10-17 11:57:53	xkbcomp: Never drop X11 canonical key types There are 4 mandatory canonical key types in the XKB protocol: - `ONE_LEVEL` - `TWO_LEVEL` - `ALPHABETIC` - `KEYPAD` They are always present in the keymap generated from xkeyboard-config. But since 31900860c65b88e4d10ad7dd00377e2815cca0f6 we drop unused key types by default, which may happen for the types hereinabove with e.g. 4+ level layouts like `es`. In theory these types are automatically filled by libX11 if missing, but there are some bugs in the X11 ecosystem that prevents the keymap to be properly uploaded in the X server, leading to errors when retrieving it with libxkbcommon-x11. See: https://gitlab.archlinux.org/archlinux/packaging/packages/libxkbcommon/-/issues/3 The following fixes were filed to fix the issues: - https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/292 - https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2082 - https://github.com/xkbcommon/libxkbcommon/pull/871 However it’s not clear when new versions of libX11 and xserver will be released. So this commit is a hack to ensure that we do not drop the XKB canonical key types, as an effort to reduce breakage. WARNING: contrary to `xkbcomp`, we do not supply these types if they are missing, because a keymap that uses them (explicitly `type="…"` or implicitly with automatic types) without providing them is considered buggy. The only exception is if no key type is provided, a default one- level type `ONE_LEVEL` is provided and assigned to all keys.
fcc95275	2025-10-17 11:56:48	xkbcomp: Rename fallback key type to ONE_LEVEL This is the name of this canonical key type in the XKB protocol.
837dbb46	2025-10-09 18:10:22	Fix C11 syntax Label followed by declaration requires C23.
6876e99d	2025-10-09 11:27:18	keymap: Fixed action comparison Before this commit there were 2 issues in action comparison: - Private actions comparison wrongly compared pointers; - Custom action types were mistakenly interpreted as errors and thus always failed comparison. Also added assertions on the action type enum so that the relevant code must be updated when the enum changes.
31900860	2025-09-30 13:05:43	keymap: Make serialization of unused items optional When compiling a keymap from text, some items may be unnecessary in the final keymap, i.e. they do not affect the keymap behavior: - unused key types; - unused keysym interpretations. Deactivate the serialization of these items by default and add a new flag to enable it for debugging.
e3ef7a47	2025-09-24 20:29:22	keymap: Warn for numeric keysyms only at high verbosity Now that the default serialization uses the numeric format for keysyms, the warning should be enabled only at maximum verbosity.
345f0c67	2025-09-24 20:28:00	keymap: Make pretty-printing optional This greatly improves the keymap serialization: 1.22× speedup and about 5% less allocations. The resulting keymap is also a bit faster to parse. Another improvement is that it eases keysym names migrations (removal and additions) by using only keysym numeric values. This requires some care, i.e. `NoSymbol` must be serialized with its name and not its value 0x0, because xkbcomp and libxkbcommon < 1.12 would interpret the numeric value as `XKB_KEY_0`.
9131711a	2025-08-21 13:09:04	keymap: Add xkb_keymap_get_as_string2() Enable to configure the keymap serialization.
181bc9ec	2025-09-24 20:10:00	xkbcomp: Fix numeric keysym parsing Keysyms written as single decimal digits are interpreted in the range `XKB_KEY_0`..`XKB_KEY_9`, consistent with the general interpretation `<name>` -> `XKB_KEY_<name>`, e.g.: - `1` → `XKB_KEY_1` - `a` → `XKB_KEY_a` However, before this commit integers in the range 0..9 in any format were treated as digit keysyms, which is wrong if the number is written with 2+ characters. E.g. the following were wrongly treated as the keysym digit `XKB_KEY_1`: `01`, `0x1`. Fixed by introducing a new token type to handle this corner case. This is a preparatory work to enable serializing keysyms as numbers.
b09aa7c6	2025-09-21 19:05:27	xkbcomp: Drop the key name LUT after compilation Since it is not usual to lookup for keys by their names, we can drop it to save allocations (about 2KiB on usual keymaps). We use an union of the LUT with the aliases array and try to reuse the memory allocated by the LUT. We only do so if the space is trivially available: either before the first alias entry or after the last entry, which is possible in practice, so that we get the best performance. Else we allocate a new array.