kmx git

Commit	Date	Message
45a118d5	2025-10-23T07:30:40	x11: Ensure LED and modifier counts are valid
54d188c7	2025-10-21T13:40:06	build: Restrict Compose fallback test in cross-compiling Do not perform the test if the build machine cannot run host binaries. Instead fallback to detect if the `newlocale` lib is known to fail on missing locales, as we expect.
8b30b24b	2025-10-20T18:48:26	doc: Minor syntax fixes
bdf069f9	2025-10-20T17:24:58	Bump version to 1.12.2
22799562	2025-10-20T13:07:58	compose: No fallback if no missing locale detection Do not use `newlocale()` if it accepts missing locales. It happens with muslc, while glibc works as expected. It fixes the incorrect behavior of the fallback introduced in 135b3204a15838205c97e793cd41faa742d429e2.
f6429933	2025-10-20T09:29:05	context: Add legacy X11 include path for misconfigured setups Some setups use the assumption that the canonical XKB root is always the legacy X11 one, but this is no longer true since xkeyboard-config 2.45, where the X11 path is now a mere symlink to a dedicated data directory for xkeyboard-config. Fixed by using a fallback to the legacy X11 path for misconfigured setups where the canonical XKB root is not available. This fallback can still be skipped if the environment variable `XKB_CONFIG_ROOT` is deliberately set to an empty string.
6d64fc5b	2025-10-20T09:02:58	context: Raise the log level of include path addition to info This information is quite important to investigate bugs and should not require the bloat of the debug log level. Also report include paths additions attempts in registry.
d2d40ec8	2025-10-20T11:14:44	context: Minor refactor
9dd55436	2025-10-20T11:13:02	context: Fix NULL include path - Fix an unlikely addition of a NULL include path in case of a failed allocation. - Fix displaying this NULL value.
c11c19fa	2025-10-20T11:10:55	context: Comment handling of empty include paths
3c0eb068	2025-10-17T14:50:07	Bump version to 1.12.1
33dc9844	2025-10-17T16:10:28	doc: Advise XKB_CONTEXT_NO_DEFAULT_INCLUDES for clients
3666f2e0	2025-10-17T15:31:09	xkbcli-list: Minor improvements
6822fa0e	2025-10-16T08:11:27	x11: Fix parsing key types level names Fixed handling missing or incomplete key types level names.
fcc95275	2025-10-17T11:56:48	xkbcomp: Rename fallback key type to ONE_LEVEL This is the name of this canonical key type in the XKB protocol.
939bf0e1	2025-10-17T11: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.
d1a1a17a	2025-10-11T19:13:11	interactive-wayland: Prevent buffer use after free The tool would crash on the second call to `buffer_create` calling `wl_buffer_destroy` on a dangling `inter->buf`. Fixes: e13faebb2a5a2b250a9c320515942edc1e652649
f4e247e5	2025-10-10T10:10:10	Bump version to 1.12.0
837dbb46	2025-10-09T18:10:22	Fix C11 syntax Label followed by declaration requires C23.
6876e99d	2025-10-09T11: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.
b9b244e2	2025-10-09T11:25:28	keymap: Add function to compare keymaps - Added private API `xkb_keymap_compare()` - Added corresponding tests
d1cd0d5f	2025-10-08T20:43:46	test: Fix tools options parsing a83a482c71719b9c46c499952656372161cc8afb introduced the new tools `xkbcli-{interactive,dump-keymap}`, along with their corresponding tests. However, these tools cannot be tested because they hardcode the paths of the `xkbcli-{interactive,dump-keymap}-{wayland,x11}` tools they call to the install directory, while we need to use those of the build directory. It seems that it got unnoticed thanks to: - the special settings in the CI: unset `*DISPLAY` environment variables; - a local installation of the development version in the developer’ setup.
584e0690	2025-10-08T11:55:22	keysyms: Update using latest xorgproto xorgproto commit: 81931cc0fd4761b42603f7da7d4f50fc282cecc6 Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/103
d0e6214c	2025-10-08T09:46:43	build: Enable using default XKB root from recent xkeyboard-config The default XKB root directory is now set from the most recent xkeyboard-config installed package, in case [multiple versions] are installed in parallel. It also try to use the package-specific XKB root (if available) rather than the X11 root, respectively defined by the pkg-config variables `xkb_root` (xkeyboard-config ≥ 2.45) and `xkb_base`. If no such package is found, it fallbacks to the historical X11 directory, as previously. [multiple versions]: https://xkeyboard-config.freedesktop.org/doc/versioning/
5e3011ce	2025-10-06T08:35:47	Fix invalid macro in xkbcli-how-to-type.1 `.Be` is not a valid macro. I believe the intent was to end the list opened with `.Bl`. The macro for that is `.El`, as used elsewhere. https://mandoc.bsd.lv/man/mdoc.7.html#Displays_and_lists
7c9f8668	2025-09-30T13:10:13	tools: Add option drop unused bits
31900860	2025-09-30T13: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.
6e45c83c	2025-09-24T20:30:40	tools: Add option to disable pretty-printing
e3ef7a47	2025-09-24T20: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-24T20: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-21T13:09:04	keymap: Add xkb_keymap_get_as_string2() Enable to configure the keymap serialization.
1bbd317f	2025-09-25T10:57:22	test: Improve Xorg xkbcomp handling - More robust call to xkbcomp. - Enable to test roundtrip with user-provided keymap.
181bc9ec	2025-09-24T20: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-21T19: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.
4421a358	2025-09-22T10:49:18	xkbcomp: Use keycode name LUT for xkb_symbols Replace linear search with O(1). On my setup I get 1.05x speedup compared to previous commit and 1.09x speedup compared to 44fad8a067d221ec0365455bc00c4c3c94bca0ad (no keycode name LUT).
79741554	2025-09-20T15:21:16	xkbcomp: Enable aliases to override keys Contrary to Xorg’s xkbcomp, keys and aliases share the same namespace. So we need to resolve name conflicts as they arise, while xkbcomp will resolve them just before copying aliases into the keymap. The following example: xkb_keycodes { <A> = 8; <B> = 9; alias <B> = <A>; }; will resolve in libxkbcommon to: xkb_keycodes { <A> = 8; alias <B> = <A>; }; while in Xorg’s xkbcomp: xkb_keycodes { <A> = 8; <B> = 9; }; The former does result in the intended mapping. In practice, there is no such conflict in xkeyboard-config. Another corner case is that now an alias can override a key even if proved invalid aftwerwards, e.g.: xkb_keycodes { <A> = 1; <B> = 2; alias <B> = <C>; /* Override key, even if invalid entry */ }; results in: xkb_keycodes { <A> = 1; }; This should be considered a bug in either the keycodes or rules files, not libxkbcommon.
b833d193	2025-09-15T14:07:05	xkbcomp: Use keycode name LUT for xkb_keycodes Replace linear search of keycode names with O(1). Given that: - the number of atoms is usually < 1k; - the keycode section usually appears first; then the first atoms will be mostly the keycodes and their aliases, so we can achieve O(1) lookup of the key names by using a simple atom → keycode array. The LUT will be used also to process `xkb_symbols` for further speedup. On my setup I get a 1.039x speedup at the costs of less than 1% additional allocations.
1eb34399	2025-08-20T22:52:17	xkbcomp: Enable using the whole keycode range In 502e9e5bff3781cba09f3b33ec030522b549f4e5 we restricted the supported keycode range in order to avoid memory exhaustion and inefficient storage in sparse arrays. This solution enabled keycodes up to 0xfff, which seemed good enough at the time. However there are huge keycodes in use in the wild, e.g. in WebOS. So let’s enable the whole keycode range by using 2 methods of storage: - “Low” keycodes (≤ 0xfff): stored contiguously as before at indexes [0..num_keys_low); fast O(1) access. - “High” keycodes (> 0xfff): stored noncontiguously at indexes [num_keys_low..num_keys); slow access via binary search.
f1376a2a	2025-09-15T19:33:26	context: Fix xkb_atom_t definition `xkb_atom_t` is in fact an index in a `darray`, so ensure the types match. This is unlikely to have any impact on modern systems.
3203a010	2025-08-13T17:06:20	tools: Add internal introspection This tool enables simple analysis of XKB files with a YAML or DOT output: - resolve XKB paths; - list sections of a file; - list the includes of each section; - optionally process each include recursively. Additionally, the RDF Turtle output enables to query using the powerful SPARQL language. The tool is for internal use only for now, so that we can test it in various use cases before deciding if making it public.
4d396f6d	2025-09-16T21:05:27	tools: Added KcCGST output in YAML
38a2081f	2025-09-17T16:17:55	utils: Add strcpy_safe This is a safe version of strcpy.
0a874a3a	2025-08-13T17:02:21	include: Enable to return the resolved path
74dcc84a	2025-09-02T05:59:34	build(deps): bump actions/upload-pages-artifact from 3 to 4 Bumps [actions/upload-pages-artifact](https://github.com/actions/upload-pages-artifact) from 3 to 4. - [Release notes](https://github.com/actions/upload-pages-artifact/releases) - [Commits](https://github.com/actions/upload-pages-artifact/compare/v3...v4) --- updated-dependencies: - dependency-name: actions/upload-pages-artifact dependency-version: '4' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
c2b2b702	2025-09-02T05:53:23	build(deps): bump actions/checkout from 4 to 5 Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 5. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](https://github.com/actions/checkout/compare/v4...v5) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
44fad8a0	2025-09-14T10:29:41	keysyms: Update to Unicode 17.0 See: https://www.unicode.org/versions/Unicode17.0.0/
de06f29f	2025-09-14T09:21:39	keysyms: Enable to use UCD files instead of ICU This enables to use a local Unicode Character Database instead of ICU via Python. Useful when ICU is not available or when it does not support the latest Unicode version. Data are available at: https://www.unicode.org/Public/<UNICODE_VERSION>/ucd
8a5a3393	2025-09-13T17:44:55	keysyms: Minor header fixes
cb53e79e	2025-09-13T17:37:10	keysyms: Update keysym data
48ba7aef	2025-09-02T10:42:19	doc: Fix figure markup
39481fec	2025-09-02T10:08:49	doc: Improve include paths
4b6fc7d8	2025-09-02T09:49:54	doc: Improve User-configuration
934d4fd8	2025-08-21T19:33:28	logging: Improve tools & benches
87042776	2025-08-21T19:30:37	logging: Encode verbosity values in an enum This enables to provide semantics and to ensure we use the values uniformly in the code base. While one could expect that verbosity `0` silences the logging, it is actually our default verbosity level for a long time. So this commit does not change that in order to avoid possible breakage. Silencing the logging is achieved by using a negative value for the verbosity level.
135b3204	2025-08-16T12:59:20	compose: Add fallback for custom locales Before this commit, loading a Compose file based on the locale would fail if the locale is not in the X11 Compose locale registry. While there are workarounds (e.g. `~/.XCompose` file or `$XCOMPOSEFILE`), it does not work if the corresponding file has `include "%L"`. This commit adds the fallback `en_US.UTF-8` in case the locale is installed but not registered in the X11 Compose locale registry. The choice is motivated by the fact that most locales use `en_US.UTF-8` anyway. Ideally we should have a mechanism to extend the Compose locale registry at the system level. Mechanisms at the user level (e.g. custom Compose file, environment variable) are deemed sufficient. We could still improve it by first trying to fallback to the locale without the country bits, but there is no function to do such function in the stdlib and we do not want to mess with locales manually. Unfortunately is not possible to test it in our test suite. One can still check it works following these instructions: 1. Create a custom locale, e.g. `en_XX.UTF-8`. `glibc-i18ndata` or similar package may be required to get the required files in `/usr/share/i18n/`. `sudo localedef -i en_US -f UTF-8 en_XX.UTF-8` 2. `xkbcli compile-compose --verbose --locale en_XX.UTF-8`
3449f69f	2025-08-16T12:57:49	doc: Add new message XKB_ERROR_INVALID_COMPOSE_LOCALE
4bfae8de	2025-08-15T16:28:39	doc: Add example to get the list of keys triggering a modifier Also add the corresponding test, so that we keep the doc in sync.
5aef5b6d	2025-08-14T09:53:34	test: Fix invalid YAML output in xkeyboard-config script
28ea23d2	2025-08-10T19:41:12	doc: Update wayland-devel links The mailing list has been migrated to Mailman 3.
0f9cefb1	2025-07-15T12:35:34	Bump version to 1.11.0
9cdf3af0	2025-08-08T19:31:33	doc: Miscellaneous enhancements - Fix minor tag typos - Add more links to the README
3ffb7e73	2025-07-16T19:43:27	doc: Add text format sections to release notes
eb8697e2	2025-07-23T15:21:39	doc: Clarify keymap format use in protocols
13ae4a26	2025-08-06T20:07:16	tools: Add Compose support to how-to-type - Enable Compose support by default; disable it with `--disable-compose` - Some filters are used to avoid combinatorial explosion
b5d969dd	2025-08-06T17:22:38	compose: Move constants to dedicated header
7394a3c7	2025-08-06T20:47:07	tools: Fix how-to-type modifier mask test
39726cac	2025-08-06T20:29:26	Add xkb_keymap_mod_get_mask2() Retrospectively, `xkb_keymap_mod_get_mask()` should have used a modifier index rather that a modifier name in its type. Since we already published a version with this API, it’s too late to change that, so instead add a new function `xkb_keymap_mod_get_mask2()`.
055c5362	2025-08-06T14:09:35	tools: Do not use a window for dump-keymap-wayland Previously a window would appear for a very short time, which is unpleasant and potentially dangerous for people sensitive to flashes.
6df45124	2025-08-05T10:19:48	tools: Add --keymap to xkbcli-how-to-type It enables to load the keymap from a file or stdin instead of resolving RMLVO names. Piping is also interesting for using with `dump-keymap-*` tools.
09e93fa0	2025-08-06T10:12:39	tools: Enable custom keymap with interactive-{x11,wayland} Added the `--keymap` option to enable providing the keymap to use instead of the one from the display server. Implies `--local-state`. Note that the other RMLVO options do not need to be implemented, since one can simply pipe a keymap from `xkbcli compile-keymap`. The `--keymap` option is also useful for users that do not have the input permissions to access evdev API.
0aa54741	2025-08-04T22:46:36	tools: Add --local-state for interactive-{x11,wayland} Enable to use a local state machine and ignore server updates for modifiers/groups. Only key press/release and new keymap events are used.
885f8129	2025-08-05T23:17:29	tools: Fix memory leak in interactive-wayland
9cc19e4e	2025-08-04T22:42:34	tools: Fix missing --verbose doc + misc
9d4885df	2025-08-04T14:31:13	tools: Improve how-to-type keysym parsing - Fixed incorrect numeric keysym parsing due to `errno` not being reset. - Added parsing keysym as fallback when `--keysym` is omitted. - Added arguments tests. - Fixed tools test Python types. - Updated documentation.
5f6f44c9	2025-08-04T14:31:26	test: Add missing tools arguments checks
29579ad4	2025-08-04T12:35:25	tools: Add --verbose to all tools Added `--verbose` to: - `xkbcli interactive-wayland` - `xkbcli interactive-x11` - `xkbcli compile-compose` - `xkbcli how-to-type`
6fac73f3	2025-08-02T09:49:44	log: Fix NULL string Fixed regression introduced in 05d13d5f41d94c7776456d856fccb5969e8f5b0a.
1e0c5790	2025-07-23T12:09:32	keysyms: Fix XF86MediaSelectAuxiliary typo
f5d079f5	2025-08-04T09:58:42	tools: Improve interactive events output Improved the output of events for `xkbcli interactive-*` tools: - Added `--multiline` to enable multiline event output, which provides more details and does not have formatting limitations. - Added `--uniline` to enable uniline event output. While this is the current default, future versions may switch to multiline display.
cce63b90	2025-08-04T09:48:32	tools: Print interactive state changes `xkbcli interactive-*` tools: print detailed state change events.
d8caabf5	2025-08-04T09:30:48	tools: Print interactive key release event `xkbcli interactive-*` tools: - Print key release events. This is particularly useful when analyzing the output sent by another person, in order to know the exact key sequence.
e9fd95a5	2025-07-23T10:01:45	keysyms: Update using latest xorgproto xorgproto commit: 7fc33fe6d9cf0abc9b62ee976e5cb7ddcd050d1f Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/93
a83a482c	2025-07-18T11:27:52	tools: Add variants with automatic session type detection Added: - `xkbcli-interactive` - `xkbcli-dump-keymap`
d60b3213	2025-07-16T08:00:30	Make the ref counting invariants explicit with assertions
93818226	2025-07-15T11:34:06	Add xkb_rmlvo_builder_ref()
dc63e5f8	2025-07-07T12:28:24	Ensure config.h is always included first While `config.h` may not be necessary in every file, it ensures consistency and makes code refactoring safer.
b21a58d0	2025-07-01T14:52:11	Add support for all level indices to LevelN constants Note that serialization must use numbers instead of names for levels > 8, to ensure backward compatibility.
e73d1a4d	2025-07-01T13:05:44	Add support for all layout indices to GroupN constants This commit enables to use the pattern `Group<INDEX>` for any valid group index `<INDEX>`. Note that the original code in xkbcomp allows constants up to `Group8`, but then will fail if the resulting group is > 4. There does not seem to be any use case for this for such “feature”; it seems rather to be a relic from times were the 4-groups limit was not hopelessly fixed in X. So for consistency in our code base, starting with this commit we now disallow `Group5`..`Group8` for keymap format v1, since it is limited to 4 groups. Also fixed a regression in the serialization of group action, when the group is relative.
64b1b9d7	2025-07-01T13:03:59	utils: Optimize istreq_prefix
9600981a	2025-07-01T15:54:09	bench: Add --keymap to compile-keymap `--keymap` enables using a keymap file rather than resolving RMLVO.
84914512	2025-07-01T18:37:22	chore: Rename indexes to indices Before this commit there was a mix between the two forms. While “indexes” is correct, “indices” is more usual and also the historical form used in this project.
58373807	2025-06-27T18:21:19	keysym: Do not convert UTF-32 to deprecated keysyms Before this commit, some code points could be converted to deprecated keysym. This is incorrect, because the relevant keysyms are all deprecated because their mapping to Unicode is uncertain! Ensure that `xkb_utf32_to_keysym()` never returns deprecated keysyms, because there is either another non-deprecated keysym or in last resort we always have the correct keysym available in the Unicode keysym range.
05d13d5f	2025-06-26T16:58:50	include: Fix infinite loop Fixed including an absolute path with no default map triggering an infinite loop.
1de49d16	2025-06-25T17:04:46	doc: Fix headers markup - Fixed a lot of broken internal links. - Improved the markup of code items. - Fixed a few typos.
447b7739	2025-06-22T10:27:31	test: Add examples for breaking latches using VoidAction() Consider the following use cases: 1. If `Caps_Lock` is on the second level of some key, and `Shift` is latched, pressing the key locks `Caps` while also breaking the `Shift` latch, ensuring that the next character is properly uppercase. 2. On the German E1 layout, `ISO_Level5_Latch` is on the third level of `<AC04>`. So if a level 3 latch is used to access it, the level 5 must break the previous level 3 latch, else both latches would be active: the effective level would be 7 instead of the intended 5. Both uses cases can be implemented using existing features: - multiple actions per level; - `VoidAction()`: to break latches.
c4f4ba41	2025-06-23T18:15:18	state: Fix modifier and group latch Prior to this commit, the sequences: - 1. latch A ↓ 2. latch B ↓ 3. latch B ↑ 4. latch A ↑ - 1. latch A ↓ 2. latch B ↓ 3. latch A ↑ 4. latch B ↑ would result in only B being latched, because the XKB protocol specifies that latches are triggered only if keys are sequentially tapped, i.e. a strict sequence of press and release of each key. It seems an unnecessary limitation: - `SlowKeys` and `XkbAX_TwoKeys` are the proper accessibility features to control accidental key presses, not latches nor `StickyKeys`. - Latches are also used outside their original accessibility role. A user may activate multiple latch keys simultaneously: - same hand: two latch keys being close to each other; - different hand: two keys being activated independently. Changed the latching behavior so that the rules used to break a latch are the same than those used to prevent it. Depressing and releasing two latching keys simultaneously will now activate both latches, as expected. Since this is a breaking change, it is enabled only by the keymap format `XKB_KEYMAP_FORMAT_TEXT_V2`.
3d00222e	2025-06-21T18:26:34	keymap: Add option `unlockOnPress` for LatchMods() It mirrors the feature of `SetMods()`, so that `StickyKeys` can be implemented.
d192b3b6	2025-06-19T21:57:46	keymap: Add option `unlockOnPress` for SetMods() It enables e.g. to deactivate `CapsLock` on press rather than on release, as in other platforms such as Windows. It fixes a [18-year old issue] inherited from the X11 ecosystem, by extending the [XKB protocol key actions]. As it is incompatible with X11, this feature is available only using the keymap text format v2. [18-year old issue]: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/74 [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions
ee87f6ed	2025-06-21T19:28:53	state: Fix broken latch not honoring clearLocks=no Before this commit, breaking a latch (modifier & group) would always clear locks, even if `clearLocks=no`.
94d8e341	2025-06-21T13:17:16	state: Fix LatchMods mutation to SetMods or LockMods Previously we use inlined version of the corresponding filter functions of the `SetMods()` and `LockMods()` actions, but they were incomplete and did not set some fields (`priv`, `refcnt`) properly. Also, it is error-prone: it requires discipline to keep it in sync. E.g. before this commit, converting to `LockMods()` would always try to unlock `CapsLock` due to the wrong value of the `priv` field. Fixed by using the corresponding filter functions directly, so that we always mutate the filter properly, as in `xkb_filter_group_latch_func`.

45a118d5

2025-10-23T07:30:40

x11: Ensure LED and modifier counts are valid

54d188c7

2025-10-21T13:40:06

build: Restrict Compose fallback test in cross-compiling Do not perform the test if the build machine cannot run host binaries. Instead fallback to detect if the `newlocale` lib is *known* to fail on missing locales, as we expect.

8b30b24b

2025-10-20T18:48:26

doc: Minor syntax fixes

bdf069f9

2025-10-20T17:24:58

Bump version to 1.12.2

22799562

2025-10-20T13:07:58

compose: No fallback if no missing locale detection Do not use `newlocale()` if it accepts missing locales. It happens with muslc, while glibc works as expected. It fixes the incorrect behavior of the fallback introduced in 135b3204a15838205c97e793cd41faa742d429e2.

f6429933

2025-10-20T09:29:05

context: Add legacy X11 include path for misconfigured setups Some setups use the assumption that the canonical XKB root is always the legacy X11 one, but this is no longer true since xkeyboard-config 2.45, where the X11 path is now a mere symlink to a dedicated data directory for xkeyboard-config. Fixed by using a fallback to the legacy X11 path for misconfigured setups where the canonical XKB root is not available. This fallback can still be skipped if the environment variable `XKB_CONFIG_ROOT` is deliberately set to an empty string.

6d64fc5b

2025-10-20T09:02:58

context: Raise the log level of include path addition to info This information is quite important to investigate bugs and should not require the bloat of the debug log level. Also report include paths additions attempts in registry.

d2d40ec8

2025-10-20T11:14:44

context: Minor refactor

9dd55436

2025-10-20T11:13:02

context: Fix NULL include path - Fix an unlikely addition of a NULL include path in case of a failed allocation. - Fix displaying this NULL value.

c11c19fa

2025-10-20T11:10:55

context: Comment handling of empty include paths

3c0eb068

2025-10-17T14:50:07

Bump version to 1.12.1

33dc9844

2025-10-17T16:10:28

doc: Advise XKB_CONTEXT_NO_DEFAULT_INCLUDES for clients

3666f2e0

2025-10-17T15:31:09

xkbcli-list: Minor improvements

6822fa0e

2025-10-16T08:11:27

x11: Fix parsing key types level names Fixed handling missing or incomplete key types level names.

fcc95275

2025-10-17T11:56:48

xkbcomp: Rename fallback key type to ONE_LEVEL This is the name of this canonical key type in the XKB protocol.

939bf0e1

2025-10-17T11: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.

d1a1a17a

2025-10-11T19:13:11

interactive-wayland: Prevent buffer use after free The tool would crash on the second call to `buffer_create` calling `wl_buffer_destroy` on a dangling `inter->buf`. Fixes: e13faebb2a5a2b250a9c320515942edc1e652649

f4e247e5

2025-10-10T10:10:10

Bump version to 1.12.0

837dbb46

2025-10-09T18:10:22

Fix C11 syntax Label followed by declaration requires C23.

6876e99d

2025-10-09T11: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.

b9b244e2

2025-10-09T11:25:28

keymap: Add function to compare keymaps - Added private API `xkb_keymap_compare()` - Added corresponding tests

d1cd0d5f

2025-10-08T20:43:46

test: Fix tools options parsing a83a482c71719b9c46c499952656372161cc8afb introduced the new tools `xkbcli-{interactive,dump-keymap}`, along with their corresponding tests. However, these tools cannot be tested because they hardcode the paths of the `xkbcli-{interactive,dump-keymap}-{wayland,x11}` tools they call to the *install* directory, while we need to use those of the *build* directory. It seems that it got unnoticed thanks to: - the special settings in the CI: unset `*DISPLAY` environment variables; - a local installation of the development version in the developer’ setup.

584e0690

2025-10-08T11:55:22

keysyms: Update using latest xorgproto xorgproto commit: 81931cc0fd4761b42603f7da7d4f50fc282cecc6 Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/103

d0e6214c

2025-10-08T09:46:43

build: Enable using default XKB root from recent xkeyboard-config The *default* XKB root directory is now set from the *most recent* xkeyboard-config installed package, in case [multiple versions] are installed in parallel. It also try to use the package-specific XKB root (if available) rather than the X11 root, respectively defined by the pkg-config variables `xkb_root` (xkeyboard-config ≥ 2.45) and `xkb_base`. If no such package is found, it fallbacks to the historical X11 directory, as previously. [multiple versions]: https://xkeyboard-config.freedesktop.org/doc/versioning/

5e3011ce

2025-10-06T08:35:47

Fix invalid macro in xkbcli-how-to-type.1 `.Be` is not a valid macro. I believe the intent was to end the list opened with `.Bl`. The macro for that is `.El`, as used elsewhere. https://mandoc.bsd.lv/man/mdoc.7.html#Displays_and_lists

7c9f8668

2025-09-30T13:10:13

tools: Add option drop unused bits

31900860

2025-09-30T13: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.

6e45c83c

2025-09-24T20:30:40

tools: Add option to disable pretty-printing

e3ef7a47

2025-09-24T20: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-24T20: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-21T13:09:04

keymap: Add xkb_keymap_get_as_string2() Enable to configure the keymap serialization.

1bbd317f

2025-09-25T10:57:22

test: Improve Xorg xkbcomp handling - More robust call to xkbcomp. - Enable to test roundtrip with user-provided keymap.

181bc9ec

2025-09-24T20: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-21T19: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.

4421a358

2025-09-22T10:49:18

xkbcomp: Use keycode name LUT for xkb_symbols Replace linear search with O(1). On my setup I get 1.05x speedup compared to previous commit and 1.09x speedup compared to 44fad8a067d221ec0365455bc00c4c3c94bca0ad (no keycode name LUT).

79741554

2025-09-20T15:21:16

xkbcomp: Enable aliases to override keys Contrary to Xorg’s xkbcomp, keys and aliases share the same namespace. So we need to resolve name conflicts as they arise, while xkbcomp will resolve them just before copying aliases into the keymap. The following example: xkb_keycodes { <A> = 8; = 9; alias = <A>; }; will resolve in libxkbcommon to: xkb_keycodes { <A> = 8; alias = <A>; }; while in Xorg’s xkbcomp: xkb_keycodes { <A> = 8; = 9; }; The former does result in the intended mapping. In practice, there is no such conflict in xkeyboard-config. Another corner case is that now an alias can override a key even if proved invalid aftwerwards, e.g.: xkb_keycodes { <A> = 1; = 2; alias = <C>; /* Override key, even if invalid entry */ }; results in: xkb_keycodes { <A> = 1; }; This should be considered a bug in either the keycodes or rules files, not libxkbcommon.

b833d193

2025-09-15T14:07:05

xkbcomp: Use keycode name LUT for xkb_keycodes Replace linear search of keycode names with O(1). Given that: - the number of atoms is usually < 1k; - the keycode section usually appears first; then the first atoms will be mostly the keycodes and their aliases, so we can achieve O(1) lookup of the key names by using a simple atom → keycode array. The LUT will be used also to process `xkb_symbols` for further speedup. On my setup I get a 1.039x speedup at the costs of less than 1% additional allocations.

1eb34399

2025-08-20T22:52:17

xkbcomp: Enable using the whole keycode range In 502e9e5bff3781cba09f3b33ec030522b549f4e5 we restricted the supported keycode range in order to avoid memory exhaustion and inefficient storage in sparse arrays. This solution enabled keycodes up to 0xfff, which seemed good enough at the time. However there are huge keycodes in use in the wild, e.g. in WebOS. So let’s enable the whole keycode range by using 2 methods of storage: - “Low” keycodes (≤ 0xfff): stored contiguously as before at indexes [0..num_keys_low); fast O(1) access. - “High” keycodes (> 0xfff): stored noncontiguously at indexes [num_keys_low..num_keys); slow access via binary search.

f1376a2a

2025-09-15T19:33:26

context: Fix xkb_atom_t definition `xkb_atom_t` is in fact an index in a `darray`, so ensure the types match. This is unlikely to have any impact on modern systems.

3203a010

2025-08-13T17:06:20

tools: Add internal introspection This tool enables simple analysis of XKB files with a YAML or DOT output: - resolve XKB paths; - list sections of a file; - list the includes of each section; - optionally process each include recursively. Additionally, the RDF Turtle output enables to query using the powerful SPARQL language. The tool is for internal use only for now, so that we can test it in various use cases before deciding if making it public.

4d396f6d

2025-09-16T21:05:27

tools: Added KcCGST output in YAML

38a2081f

2025-09-17T16:17:55

utils: Add strcpy_safe This is a safe version of strcpy.

0a874a3a

2025-08-13T17:02:21

include: Enable to return the resolved path

74dcc84a

2025-09-02T05:59:34

build(deps): bump actions/upload-pages-artifact from 3 to 4 Bumps [actions/upload-pages-artifact](https://github.com/actions/upload-pages-artifact) from 3 to 4. - [Release notes](https://github.com/actions/upload-pages-artifact/releases) - [Commits](https://github.com/actions/upload-pages-artifact/compare/v3...v4) --- updated-dependencies: - dependency-name: actions/upload-pages-artifact dependency-version: '4' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>

c2b2b702

2025-09-02T05:53:23

build(deps): bump actions/checkout from 4 to 5 Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 5. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](https://github.com/actions/checkout/compare/v4...v5) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>

44fad8a0

2025-09-14T10:29:41

keysyms: Update to Unicode 17.0 See: https://www.unicode.org/versions/Unicode17.0.0/

de06f29f

2025-09-14T09:21:39

keysyms: Enable to use UCD files instead of ICU This enables to use a local Unicode Character Database instead of ICU via Python. Useful when ICU is not available or when it does not support the latest Unicode version. Data are available at: https://www.unicode.org/Public/<UNICODE_VERSION>/ucd

8a5a3393

2025-09-13T17:44:55

keysyms: Minor header fixes

cb53e79e

2025-09-13T17:37:10

keysyms: Update keysym data

48ba7aef

2025-09-02T10:42:19

doc: Fix figure markup

39481fec

2025-09-02T10:08:49

doc: Improve include paths

4b6fc7d8

2025-09-02T09:49:54

doc: Improve User-configuration

934d4fd8

2025-08-21T19:33:28

logging: Improve tools & benches

87042776

2025-08-21T19:30:37

logging: Encode verbosity values in an enum This enables to provide semantics and to ensure we use the values uniformly in the code base. While one could expect that verbosity `0` silences the logging, it is actually our default verbosity level for a long time. So this commit does not change that in order to avoid possible breakage. Silencing the logging is achieved by using a negative value for the verbosity level.

135b3204

2025-08-16T12:59:20

compose: Add fallback for custom locales Before this commit, loading a Compose file based on the locale would fail if the locale is not in the X11 Compose locale registry. While there are workarounds (e.g. `~/.XCompose` file or `$XCOMPOSEFILE`), it does not work if the corresponding file has `include "%L"`. This commit adds the fallback `en_US.UTF-8` in case the locale is installed but not registered in the X11 Compose locale registry. The choice is motivated by the fact that most locales use `en_US.UTF-8` anyway. Ideally we should have a mechanism to extend the Compose locale registry at the *system* level. Mechanisms at the user level (e.g. custom Compose file, environment variable) are deemed sufficient. We could still improve it by first trying to fallback to the locale without the country bits, but there is no function to do such function in the stdlib and we do not want to mess with locales manually. Unfortunately is not possible to test it in our test suite. One can still check it works following these instructions: 1. Create a custom locale, e.g. `en_XX.UTF-8`. `glibc-i18ndata` or similar package may be required to get the required files in `/usr/share/i18n/`. `sudo localedef -i en_US -f UTF-8 en_XX.UTF-8` 2. `xkbcli compile-compose --verbose --locale en_XX.UTF-8`

3449f69f

2025-08-16T12:57:49

doc: Add new message XKB_ERROR_INVALID_COMPOSE_LOCALE

4bfae8de

2025-08-15T16:28:39

doc: Add example to get the list of keys triggering a modifier Also add the corresponding test, so that we keep the doc in sync.

5aef5b6d

2025-08-14T09:53:34

test: Fix invalid YAML output in xkeyboard-config script

28ea23d2

2025-08-10T19:41:12

doc: Update wayland-devel links The mailing list has been migrated to Mailman 3.

0f9cefb1

2025-07-15T12:35:34

Bump version to 1.11.0

9cdf3af0

2025-08-08T19:31:33

doc: Miscellaneous enhancements - Fix minor tag typos - Add more links to the README

3ffb7e73

2025-07-16T19:43:27

doc: Add text format sections to release notes

eb8697e2

2025-07-23T15:21:39

doc: Clarify keymap format use in protocols

13ae4a26

2025-08-06T20:07:16

tools: Add Compose support to how-to-type - Enable Compose support by default; disable it with `--disable-compose` - Some filters are used to avoid combinatorial explosion

b5d969dd

2025-08-06T17:22:38

compose: Move constants to dedicated header

7394a3c7

2025-08-06T20:47:07

tools: Fix how-to-type modifier mask test

39726cac

2025-08-06T20:29:26

Add xkb_keymap_mod_get_mask2() Retrospectively, `xkb_keymap_mod_get_mask()` should have used a modifier index rather that a modifier name in its type. Since we already published a version with this API, it’s too late to change that, so instead add a new function `xkb_keymap_mod_get_mask2()`.

055c5362

2025-08-06T14:09:35

tools: Do not use a window for dump-keymap-wayland Previously a window would appear for a very short time, which is unpleasant and potentially dangerous for people sensitive to flashes.

6df45124

2025-08-05T10:19:48

tools: Add --keymap to xkbcli-how-to-type It enables to load the keymap from a file or stdin instead of resolving RMLVO names. Piping is also interesting for using with `dump-keymap-*` tools.

09e93fa0

2025-08-06T10:12:39

tools: Enable custom keymap with interactive-{x11,wayland} Added the `--keymap` option to enable providing the keymap to use instead of the one from the display server. Implies `--local-state`. Note that the other RMLVO options do not need to be implemented, since one can simply pipe a keymap from `xkbcli compile-keymap`. The `--keymap` option is also useful for users that do not have the input permissions to access evdev API.

0aa54741

2025-08-04T22:46:36

tools: Add --local-state for interactive-{x11,wayland} Enable to use a *local* state machine and ignore server updates for modifiers/groups. Only key press/release and new keymap events are used.

885f8129

2025-08-05T23:17:29

tools: Fix memory leak in interactive-wayland

9cc19e4e

2025-08-04T22:42:34

tools: Fix missing --verbose doc + misc

9d4885df

2025-08-04T14:31:13

tools: Improve how-to-type keysym parsing - Fixed incorrect numeric keysym parsing due to `errno` not being reset. - Added parsing keysym as fallback when `--keysym` is omitted. - Added arguments tests. - Fixed tools test Python types. - Updated documentation.

5f6f44c9

2025-08-04T14:31:26

test: Add missing tools arguments checks

29579ad4

2025-08-04T12:35:25

tools: Add --verbose to all tools Added `--verbose` to: - `xkbcli interactive-wayland` - `xkbcli interactive-x11` - `xkbcli compile-compose` - `xkbcli how-to-type`

6fac73f3

2025-08-02T09:49:44

log: Fix NULL string Fixed regression introduced in 05d13d5f41d94c7776456d856fccb5969e8f5b0a.

1e0c5790

2025-07-23T12:09:32

keysyms: Fix XF86MediaSelectAuxiliary typo

f5d079f5

2025-08-04T09:58:42

tools: Improve interactive events output Improved the output of events for `xkbcli interactive-*` tools: - Added `--multiline` to enable multiline event output, which provides more details and does not have formatting limitations. - Added `--uniline` to enable uniline event output. While this is the current default, future versions may switch to multiline display.

cce63b90

2025-08-04T09:48:32

tools: Print interactive state changes `xkbcli interactive-*` tools: print detailed state change events.

d8caabf5

2025-08-04T09:30:48

tools: Print interactive key release event `xkbcli interactive-*` tools: - Print key release events. This is particularly useful when analyzing the output sent by another person, in order to know the exact key sequence.

e9fd95a5

2025-07-23T10:01:45

keysyms: Update using latest xorgproto xorgproto commit: 7fc33fe6d9cf0abc9b62ee976e5cb7ddcd050d1f Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/93

a83a482c

2025-07-18T11:27:52

tools: Add variants with automatic session type detection Added: - `xkbcli-interactive` - `xkbcli-dump-keymap`

d60b3213

2025-07-16T08:00:30

Make the ref counting invariants explicit with assertions

93818226

2025-07-15T11:34:06

Add xkb_rmlvo_builder_ref()

dc63e5f8

2025-07-07T12:28:24

Ensure config.h is always included first While `config.h` may not be necessary in every file, it ensures consistency and makes code refactoring safer.

b21a58d0

2025-07-01T14:52:11

Add support for all level indices to LevelN constants Note that serialization must use numbers instead of names for levels > 8, to ensure backward compatibility.

e73d1a4d

2025-07-01T13:05:44

Add support for all layout indices to GroupN constants This commit enables to use the pattern `Group<INDEX>` for any valid group index `<INDEX>`. Note that the original code in xkbcomp allows constants up to `Group8`, but then will fail if the resulting group is > 4. There does not seem to be any use case for this for such “feature”; it seems rather to be a relic from times were the 4-groups limit was not hopelessly fixed in X. So for consistency in our code base, starting with this commit we now disallow `Group5`..`Group8` for keymap format v1, since it is limited to 4 groups. Also fixed a regression in the serialization of group action, when the group is relative.

64b1b9d7

2025-07-01T13:03:59

utils: Optimize istreq_prefix

9600981a

2025-07-01T15:54:09

bench: Add --keymap to compile-keymap `--keymap` enables using a keymap file rather than resolving RMLVO.

84914512

2025-07-01T18:37:22

chore: Rename indexes to indices Before this commit there was a mix between the two forms. While “indexes” is correct, “indices” is more usual and also the historical form used in this project.

58373807

2025-06-27T18:21:19

keysym: Do not convert UTF-32 to deprecated keysyms Before this commit, some code points could be converted to deprecated keysym. This is incorrect, because the relevant keysyms are all deprecated because their mapping to Unicode is uncertain! Ensure that `xkb_utf32_to_keysym()` never returns deprecated keysyms, because there is either another non-deprecated keysym or in last resort we always have the correct keysym available in the Unicode keysym range.

05d13d5f

2025-06-26T16:58:50

include: Fix infinite loop Fixed including an absolute path with no default map triggering an infinite loop.

1de49d16

2025-06-25T17:04:46

doc: Fix headers markup - Fixed a lot of broken internal links. - Improved the markup of code items. - Fixed a few typos.

447b7739

2025-06-22T10:27:31

test: Add examples for breaking latches using VoidAction() Consider the following use cases: 1. If `Caps_Lock` is on the second level of some key, and `Shift` is latched, pressing the key locks `Caps` while also breaking the `Shift` latch, ensuring that the next character is properly uppercase. 2. On the German E1 layout, `ISO_Level5_Latch` is on the third level of `<AC04>`. So if a level 3 latch is used to access it, the level 5 must break the previous level 3 latch, else both latches would be active: the effective level would be 7 instead of the intended 5. Both uses cases can be implemented using existing features: - multiple actions per level; - `VoidAction()`: to break latches.

c4f4ba41

2025-06-23T18:15:18

state: Fix modifier and group latch Prior to this commit, the sequences: - 1. latch A ↓ 2. latch B ↓ 3. latch B ↑ 4. latch A ↑ - 1. latch A ↓ 2. latch B ↓ 3. latch A ↑ 4. latch B ↑ would result in only B being latched, because the XKB protocol specifies that latches are triggered only if keys are *sequentially* tapped, i.e. a strict sequence of press and release of each key. It seems an unnecessary limitation: - `SlowKeys` and `XkbAX_TwoKeys` are the proper accessibility features to control accidental key presses, not latches nor `StickyKeys`. - Latches are also used outside their original accessibility role. A user may activate multiple latch keys simultaneously: - same hand: two latch keys being close to each other; - different hand: two keys being activated independently. Changed the latching behavior so that the rules used to break a latch are the same than those used to prevent it. Depressing and releasing two latching keys simultaneously will now activate both latches, as expected. Since this is a breaking change, it is enabled only by the keymap format `XKB_KEYMAP_FORMAT_TEXT_V2`.

3d00222e

2025-06-21T18:26:34

keymap: Add option `unlockOnPress` for LatchMods() It mirrors the feature of `SetMods()`, so that `StickyKeys` can be implemented.

d192b3b6

2025-06-19T21:57:46

keymap: Add option `unlockOnPress` for SetMods() It enables e.g. to deactivate `CapsLock` *on press* rather than on release, as in other platforms such as Windows. It fixes a [18-year old issue] inherited from the X11 ecosystem, by extending the [XKB protocol key actions]. As it is incompatible with X11, this feature is available only using the keymap text format v2. [18-year old issue]: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/74 [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions

ee87f6ed

2025-06-21T19:28:53

state: Fix broken latch not honoring clearLocks=no Before this commit, breaking a latch (modifier & group) would always clear locks, even if `clearLocks=no`.

94d8e341

2025-06-21T13:17:16

state: Fix LatchMods mutation to SetMods or LockMods Previously we use inlined version of the corresponding filter functions of the `SetMods()` and `LockMods()` actions, but they were incomplete and did not set some fields (`priv`, `refcnt`) properly. Also, it is error-prone: it requires discipline to keep it in sync. E.g. before this commit, converting to `LockMods()` would always try to unlock `CapsLock` due to the wrong value of the `priv` field. Fixed by using the corresponding filter functions directly, so that we always mutate the filter properly, as in `xkb_filter_group_latch_func`.

kc3-lang/libxkbcommon

Log