kc3-lang/libxkbcommon
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
f6429933 | 2025-10-20 09: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. | |
|
c11c19fa | 2025-10-20 11:10:55 | context: Comment handling of empty include paths | |
|
d2d40ec8 | 2025-10-20 11:14:44 | context: Minor refactor | |
|
9dd55436 | 2025-10-20 11: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. | |
|
6d64fc5b | 2025-10-20 09: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. | |
|
3666f2e0 | 2025-10-17 15:31:09 | xkbcli-list: Minor improvements | |
|
3c0eb068 | 2025-10-17 14:50:07 | Bump version to 1.12.1 | |
|
33dc9844 | 2025-10-17 16:10:28 | doc: Advise XKB_CONTEXT_NO_DEFAULT_INCLUDES for clients | |
|
6822fa0e | 2025-10-16 08:11:27 | x11: Fix parsing key types level names Fixed handling missing or incomplete key types level names. | |
|
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. | |
 |
d1a1a17a | 2025-10-11 19: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-10 10:10:10 | Bump version to 1.12.0 | |
|
837dbb46 | 2025-10-09 18:10:22 | Fix C11 syntax Label followed by declaration requires C23. | |
|
b9b244e2 | 2025-10-09 11:25:28 | keymap: Add function to compare keymaps - Added private API `xkb_keymap_compare()` - Added corresponding tests | |
|
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. | |
|
d1cd0d5f | 2025-10-08 20: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-08 11: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-08 09: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-06 08: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-30 13:10:13 | tools: Add option drop unused bits | |
|
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. | |
|
6e45c83c | 2025-09-24 20:30:40 | tools: Add option to disable pretty-printing | |
|
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. | |
|
1bbd317f | 2025-09-25 10:57:22 | test: Improve Xorg xkbcomp handling - More robust call to xkbcomp. - Enable to test roundtrip with user-provided keymap. | |
|
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. | |
|
b833d193 | 2025-09-15 14: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-20 22: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-15 19: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. | |
|
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. | |
|
4421a358 | 2025-09-22 10: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-20 15: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. | |
|
3203a010 | 2025-08-13 17: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-16 21:05:27 | tools: Added KcCGST output in YAML | |
|
38a2081f | 2025-09-17 16:17:55 | utils: Add strcpy_safe This is a safe version of strcpy. | |
|
0a874a3a | 2025-08-13 17:02:21 | include: Enable to return the resolved path | |
 |
74dcc84a | 2025-09-02 05: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-02 05: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-14 10:29:41 | keysyms: Update to Unicode 17.0 See: https://www.unicode.org/versions/Unicode17.0.0/ | |
|
de06f29f | 2025-09-14 09: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-13 17:44:55 | keysyms: Minor header fixes | |
|
cb53e79e | 2025-09-13 17:37:10 | keysyms: Update keysym data | |
|
48ba7aef | 2025-09-02 10:42:19 | doc: Fix figure markup | |
|
39481fec | 2025-09-02 10:08:49 | doc: Improve include paths | |
|
4b6fc7d8 | 2025-09-02 09:49:54 | doc: Improve User-configuration | |
|
934d4fd8 | 2025-08-21 19:33:28 | logging: Improve tools & benches | |
|
87042776 | 2025-08-21 19: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-16 12: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-16 12:57:49 | doc: Add new message XKB_ERROR_INVALID_COMPOSE_LOCALE | |
|
4bfae8de | 2025-08-15 16: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-14 09:53:34 | test: Fix invalid YAML output in xkeyboard-config script | |
|
28ea23d2 | 2025-08-10 19:41:12 | doc: Update wayland-devel links The mailing list has been migrated to Mailman 3. | |
|
0f9cefb1 | 2025-07-15 12:35:34 | Bump version to 1.11.0 | |
|
9cdf3af0 | 2025-08-08 19:31:33 | doc: Miscellaneous enhancements - Fix minor tag typos - Add more links to the README | |
|
3ffb7e73 | 2025-07-16 19:43:27 | doc: Add text format sections to release notes | |
|
eb8697e2 | 2025-07-23 15:21:39 | doc: Clarify keymap format use in protocols | |
|
13ae4a26 | 2025-08-06 20: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-06 17:22:38 | compose: Move constants to dedicated header | |
|
7394a3c7 | 2025-08-06 20:47:07 | tools: Fix how-to-type modifier mask test | |
|
39726cac | 2025-08-06 20: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-06 14: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-05 10: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-06 10: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-04 22: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-05 23:17:29 | tools: Fix memory leak in interactive-wayland | |
|
9cc19e4e | 2025-08-04 22:42:34 | tools: Fix missing --verbose doc + misc | |
|
9d4885df | 2025-08-04 14: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-04 14:31:26 | test: Add missing tools arguments checks | |
|
29579ad4 | 2025-08-04 12: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-02 09:49:44 | log: Fix NULL string Fixed regression introduced in 05d13d5f41d94c7776456d856fccb5969e8f5b0a. | |
|
1e0c5790 | 2025-07-23 12:09:32 | keysyms: Fix XF86MediaSelectAuxiliary typo | |
|
f5d079f5 | 2025-08-04 09: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-04 09:48:32 | tools: Print interactive state changes `xkbcli interactive-*` tools: print detailed state change events. | |
|
d8caabf5 | 2025-08-04 09: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-23 10: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-18 11:27:52 | tools: Add variants with automatic session type detection Added: - `xkbcli-interactive` - `xkbcli-dump-keymap` | |
|
d60b3213 | 2025-07-16 08:00:30 | Make the ref counting invariants explicit with assertions | |
|
93818226 | 2025-07-15 11:34:06 | Add xkb_rmlvo_builder_ref() | |
|
dc63e5f8 | 2025-07-07 12: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-01 14: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-01 13: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-01 13:03:59 | utils: Optimize istreq_prefix | |
|
9600981a | 2025-07-01 15:54:09 | bench: Add --keymap to compile-keymap `--keymap` enables using a keymap file rather than resolving RMLVO. | |
|
84914512 | 2025-07-01 18: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-27 18: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-26 16:58:50 | include: Fix infinite loop Fixed including an absolute path with no default map triggering an infinite loop. | |
|
1de49d16 | 2025-06-25 17: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-22 10: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-23 18: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-21 18:26:34 | keymap: Add option `unlockOnPress` for LatchMods() It mirrors the feature of `SetMods()`, so that `StickyKeys` can be implemented. | |
|
d192b3b6 | 2025-06-19 21: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-21 19: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-21 13: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`. | |
 |
7a7a3b38 | 2024-02-14 09:47:15 | keymap: Canonically map unmapped virtual modifiers Traditionally, *virtual* modifiers were merely name aliases for *real* modifiers (X *core* modifiers), e.g. `NumLock` was usually mapped to `Mod2` (see `modifier_map` statement). Virtual modifiers that were never mapped to a real ones had no effect on the keymap state. xkbcommon already supports the concept of “pure” virtual modifiers, i.e. virtual modifiers that are *encoded* using the full 32-bit range, not just the first 8 bits corresponding to the real modifiers. But until this commit, one had to declare such mapping *explicitly*: e.g. `virtual_modifiers M = 0x100;`. This has at least two drawbacks: - Numerical values may look quite arbitrary and are not user-friendly. It’s OK in the resulting compiled keymap, but it requires careful sync between sections when developing KcCGST files. - If the modifier is *also* mapped *implicitly* using the traditional `vmodmap`/`modifier_map`, then both mappings are OR-combined. This patch enables to automatically map unmapped virtual modifiers to their *canonical* mapping, i.e. themselves: their corresponding virtual and real modifier masks are identical: `1u << mod_index`. Since this feature is incompatible with X11, this is guarded by requiring at least keymap text format **v2**. Note that for now, canonical virtual modifiers cannot be used in an interpret action’s `AnyOf()`. An interpret action for a canonical virtual modifier must be `AnyOfOrNone()` to take effect: virtual_modifiers APureMod, …; interpret a+AnyOfOrNone(all) { virtualModifier= APureMod; action= SetMods(modifiers=APureMod); }; The above adds a virtual modifier `APureMod` for keysym `a`. It will be canonical iff it is not mapped implicitly. | |
|
d351abee | 2025-06-19 11:24:44 | test: Use explicit keymap format for test_compile_file() | |
|
56a32cc8 | 2025-06-18 11:37:19 | xkbcli-interactive-wayland: xdg-decoration-unstable-v1 Use if available, to get window decoration. Also resize the window bigger enough to make its title readable. | |
|
e13faebb | 2025-06-18 11:36:07 | xkbcli-interactive-wayland: Fix memory leak | |
|
69c3d257 | 2025-06-17 16:43:05 | keymap: Add parameter `latchOnPress` for LatchMods() Some keyboard layouts use `ISO_Level3_Latch` or `ISO_Level5_Latch` to define “built-in” dead keys: - they do not rely on the installation of custom Compose file; - they do not clash with other layouts. However, layout projects usually want the exact same behavior on all OS, but the XKB latch behavior (often misunderstood) also acts as a *set* modifier, which is not expected. The usual behavior of a dead key on Linux, macOS and Windows is: - latch on press; - deactivate as soon as another (non-modifier) key is pressed. Added the parameter `latchOnPress` to `LatchMods()` to enable the aforementioned behavior. As it is incompatible with X11, this feature is available only using the keymap text format v2. [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions |