kmx git

Commit	Date	Message
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.
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
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.
9cc19e4e	2025-08-04T22:42:34	tools: Fix missing --verbose doc + misc
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
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.
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`.
7a7a3b38	2024-02-14T09: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-19T11:24:44	test: Use explicit keymap format for test_compile_file()
56a32cc8	2025-06-18T11: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-18T11:36:07	xkbcli-interactive-wayland: Fix memory leak
69c3d257	2025-06-17T16: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
c58c7df1	2025-06-17T21:05:08	Serialize multiple actions per level to VoidAction() in v1 format When using `XKB_KEYMAP_FORMAT_TEXT_V1`, multiple actions per level are now serialized using `VoidAction()`, in order to maintain compatibility with X11.
4f2fa718	2025-06-17T16:47:20	dump: Fix typo Fixed copy-paste error. It worked for now, as both struct have the same first fields, but it is obviously semantically incorrect and not future-proof.
ee50e0c9	2025-06-12T20:14:50	keymap: Add option `unlockOnPress` for LockMods() It enables e.g. to deactivate CapsLock on press rather than on release, as in other platforms such as Windows. The specification of `LockMods()` is changed to: - On key press: - If `unlockOnPress` is true and some of the target modifiers were locked before the key press, then unlock them if `noUnlock` false. - Otherwise: - add target modifiers to depressed modifiers; - if `noLock` is false, add target modifiers to the locked modifiers. - On key release: - If `unlockOnPress` is true and triggered unlocking on key press, do nothing. - Otherwise: - remove modifiers from the depressed modifiers, if no other key that affect the same modifiers is down; - if `noUnlock` is false and if any target modifiers was locked before the key press, unlock them. It fixes a [12-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. [12-year old issue]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/312 [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions
d9d82355	2025-06-12T09:13:27	keymap: Add option `lockOnRelease` for LockGroup() It enables to use e.g. the combination `Control + Shift` alone to switch layouts, while keeping the use of `Control + Shift + other key` (typically for keyboard shortcuts). The specification of `LockGroup()` is changed to: - On key press: - If `lockOnRelease` is set, then key press has no effect. - Otherwise: - if the `group` is absolute, key press sets the locked keyboard group to `group`; - otherwise, key press adds `group` to the locked keyboard group. In either case, the resulting locked and effective group is brought back into range depending on the value of the `GroupsWrap` control for the keyboard. - On key release: - If `lockOnRelease` is not set, then key release has no effect. - Otherwise, if any other key was pressed after the locking key, then key release has no effect. - Otherwise, it has the same effect than a key press without `lockOnRelease` set. This is really useful for people coming from other platforms, such as Windows. It fixes a [20-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. [20-year old issue]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/258 [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions
c2896b32	2025-06-12T09:16:54	messages: Add new error "incompatible-keymap-text-format"
da2af4d3	2025-06-17T12:08:59	xkbcli-list: Added `layout-specific` field for options
0106b357	2025-06-17T12:06:32	registry: Add rxkb_option_is_layout_specific() Enable to query if an option accepts layout index specifiers to restrict its application to the corresponding layouts.
c4c531da	2025-06-17T11:43:50	rules: Add layout-specific options for RMLVO builder Change the signature of `xkb_rmlvo_builder_append_layout()` to accept an array of options. Also add tests for layout-specific options.
fab9d25b	2025-06-17T11:43:22	rules: Add support for layout-specific options Enabled specifying a layout index for each option, so that it applies only if the layout matches. The layout index is specified by appending immediately after the option name the `!` specifier delimiter and then the layout index, in decimal form and 1-indexed. Note that `!` was chosen instead of the usual `:` specifier delimiter, because some options contains `:`, e.g. `grp:menu_toggle`. `!` cannot clash with component names, because `!` is a token in the rules files and thus cannot be used as in component names. It is also vaguely similar to `:`, compared to e.g. `@` or `#`. Example: given the following rules: ! layout[any] option = symbol * opt1 = +s1:%i l2 opt2 = +s2:%i it may result in the following configurations: \| Layout \| Option \| Symbols \| \| -------- \| -------- \| ------------ \| \| `l1` \| `opt1` \| `+s1:1` \| \| `l2` \| `opt1` \| `+s1:1` \| \| `l1` \| `opt2` \| `` \| \| `l2` \| `opt2` \| `+s2:1` \| \| `l1,l2` \| `opt1` \| `+s1:1+s1:2` \| \| `l1,l2` \| `opt1!1` \| `+s1:1` \| \| `l1,l2` \| `opt1!2` \| `+s1:2` \| \| `l1,l2` \| `opt2` \| `+s2:2` \| \| `l1,l2` \| `opt2!1` \| `` \| \| `l1,l2` \| `opt2!2` \| `+s2:2` \|
52a4d9b0	2025-06-17T11:03:12	rules: Require layout or variant to enable %i expansion Before this commit, the following rule would always match: ! model = symbols * = s:%i and set symbols to `s:1`, but the `:%i` is aimed to be used only when the rules header specifies the layout or the variant. Let’s be strict and disallow matching this kind of buggy rule. Emit an error message so that we can detect it.
ef6a550f	2025-06-16T15:48:25	Add xkb_keymap_new_from_rmlvo() Use the new RMLVO builder API to compile keymaps.
da5caabb	2025-06-16T15:45:42	Add RMLVO builder API Before this commit, the API to work with RMLVO was quite minimal: it only uses raw strings from the `xkb_rule_names` struct. However: - it forces the users to deal with error-prone string formatting; - it does not enforce tying together layouts and variants; - it limits adding new features by requiring defining delimiter characters and the corresponding parsing. Added the following API: - `xkb_rmlvo_builder_new()` - `xkb_rmlvo_builder_append_layout()` - `xkb_rmlvo_builder_append_option()` - `xkb_rmlvo_builder_unref()` There is no intermediate `layout` nor `option` object, in order to to keep the API simple. The only foreseen extension is enabling configuring layout-specific options.
2906c7ec	2025-06-14T13:19:41	rules: Fix parsing group index There was a typo that made parsing hexadecimal instead of the expected decimal format.
f7a61da7	2025-06-10T17:33:24	doc: Update new layout count ranges
ac9cd053	2025-06-11T19:00:47	test: Check extended layout indexes
80b8d9d1	2025-06-10T17:34:15	dump: Adapt groups count to keymap format
62fe73cb	2025-06-10T17:33:14	parser: Raise the layout limit to 32
717ce258	2025-06-11T18:34:15	test: Refactor rules-file and state Split into dedicated functions fo better readability.
2535a3f9	2025-06-11T15:55:25	rules: Convert macros into enums & inline functions This provides semantics and better type-check.
7f39be25	2025-06-10T15:46:45	test: Use explicit keymap output format for test_compile_output()
9f3078eb	2025-06-10T15:46:31	dump: Use explicit format
0f89ad97	2025-06-09T19:26:13	dump: Always use numeric group indexes The upcoming raise of the maximum groups count will require to use numeric group indexes instead of the syntax `GroupN` if groups > 8. Let’s not bother with handling two cases (group count ≤ 8 or > 8) and always serialize group indexes as numeric values.
79e95509	2025-06-09T11:07:36	test: Use explicit keymap format in test_compile_rules()
f3386743	2025-06-09T16:44:54	test: Use explicit keymap format in test_compile_output()
2acf5eca	2025-06-09T16:26:56	test: Use explicit keymap format in test_compile_buffer()
6c5ea6fc	2025-06-09T16:15:20	test: Use explicit keymap format in test_compile_string()
6d67bce5	2025-06-08T10:01:02	doc: Towards and exhaustive compatibility page We need to track the compatibility with X11 with as much details as possible: - Transparency; - Facilitate answering issues by just pointing to the relevant page item; - Efficient reference documentation for development.
27ba56ae	2025-05-07T10:55:24	doc: Add initial documention for XKB_KEYMAP_FORMAT_TEXT_V2
44c8deb2	2025-05-07T10:20:25	Introduce keymap format v2 and make it the default for parsing - Added `XKB_KEYMAP_FORMAT_TEXT_V2`. - Made `xkb_keymap_new_from_names()` use the new keymap format. - Made the tools default to the new keymap format for input. This is in preparation for changes in the parsing & state handling. For now it changes nothing.
82ea2915	2025-05-06T17:22:22	tools: Add options to use explicit keymap format The default output keymap format is `XKB_KEYMAP_USE_ORIGINAL_FORMAT`.
62712cfe	2025-05-06T17:42:54	bench: Add options to use an explicit keymap format
08149dae	2025-05-06T16:23:04	Add internal API to query and parse supported keymap formats
58397e94	2025-05-06T18:05:30	Deprecate xkb_keymap_new_from_names() - Deprecate `xkb_keymap_new_from_names()` in favor of `xkb_keymap_new_from_names2()` - Add new changelog fragment type `deprecated`. - Change documentation to use the new function.
1a10f858	2025-05-06T18:05:06	Add xkb_keymap_new_from_names2 This is just `xkb_keymap_new_from_names()` with an explicit keymap format.
16c079d6	2025-06-06T20:27:45	chore: Rename is_absolute to is_absolute_path
39b4b670	2025-06-06T18:40:29	Support including keymap components using %-expansion and absolute path Enable to use the same `include` features than rules files in keymap components: - `%`-expansion: `%H` home directory, `%S` sytem root and `%E` extra. - absolute file paths. This is useful if one wants to overwrite the system file with a user config (i.e. same name, but in `~/.config/xkb`), but still include the system file: ``` // File: ~/.config/xkb/symbols/de xkb_symbols "basic" { include "%S/de(basic)" key <AB01> { [z, Z] }; key <AD06> { [y, Y] }; } ```` Without the commit, using a mere `include "de(basic)"` would result in an include loop. Refactored by using the same code for rules and keymap components.
eb0a1457	2025-06-01T18:06:59	build(deps): bump dawidd6/action-download-artifact from 9 to 10 Bumps [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) from 9 to 10. - [Release notes](https://github.com/dawidd6/action-download-artifact/releases) - [Commits](https://github.com/dawidd6/action-download-artifact/compare/v9...v10) --- updated-dependencies: - dependency-name: dawidd6/action-download-artifact dependency-version: '10' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
16ba1af0	2025-06-01T19:51:47	ci: Fix xkeyboard-config install Since xkeyboard-config 2.45 uses a symlink for: /usr/share/pkgconfig/xkeyboard-config.pc /usr/share/X11/xkb but meson cannot overwrite < 2.45 which used a regular file and directory. Fixed by first removing the files. This is still a hack and we should use a proper package update.
bffbef88	2025-05-21T23:57:11	build: Require Bison ≥ 3.6 Older versions don’t support `%define parse.error detailed`. Fixes: a3f1a9d3ba ("xkbcomp/parser: enable Bison detailed syntax error")
7888474d	2025-05-16T14:06:18	Bump version to 1.10.0
324984f1	2025-05-17T06:49:49	xkbcomp: Fix log for unknown default field
4e1fd49a	2025-05-17T07:53:10	scripts: Enable generating new range message codes
c3744cd3	2025-05-16T14:10:37	test: Fix Compose log
9b4fd82b	2025-05-13T11:46:46	test: Skip checked arithmetic if not available
e9394b9f	2025-05-13T10:47:22	utils: Use explicit cast to prevent warnings
fb9fec18	2025-05-10T10:18:38	xkbcomp: Checked arithmetic Use a polyfill for C23 checked arithmetic. This is a bit paranoid, as we expect the user to use only 32 bit integers, so the signed 64 bit integer we use to store the result should be more than enough. Use jtckdint v1.0: - repository: https://github.com/jart/jtckdint - commit: 339450d13d8636f05dcb71ba36efddb226db481e - removed all C++-specific code
7a2aa9c9	2024-12-20T22:53:11	Always retain later Compose sequence in case of conflict This ensures that it is always possible to override previous definitions, for example when `include`ing the system Compose file. Signed-off-by: Jules Bertholet <julesbertholet@quoi.xyz>
3a8bb1a1	2025-05-16T13:13:55	compose: Fix sequence not fully overriden Previously if a new sequence did not produce a keysym or a string, the corresponding property was not overriden, possibly leaking the previous entry. - Fixed by always writting all the properties. - Also try to reuse the previous string entry, if possible, so that we avoid allocating.
9da1a2eb	2025-05-16T10:33:43	doc: Add license in generated doc
d018638d	2025-05-16T09:35:39	doc: Improve CSS
61a1e646	2025-05-15T17:24:50	doc: Reformat release notes and include them in the HTML doc
bd552642	2025-05-15T17:20:44	doc: Use custom alias to fix HTML tags unsupported by Doxygen Previous solution with `sed` is both overkilled and unreliable. Prefer a hack using Doxygen’s buit-ins, although we are not sure these are much more stable… 😓
b5f7c843	2025-05-14T21:34:23	doc: Add script to fix HTML tags unsupported by Doxygen
06fbe1b2	2025-05-14T20:08:39	doc: Promote xkbcli tools
cedc54d0	2025-05-13T15:58:52	doc: Modifier declaration and binding Detailed explanation of: - modifier declaration - real/virtual modifier maps - modifier key binding - modifier encoding - modifier portability
3eaf8ad2	2025-05-14T18:39:11	doc: Add FAQ section for legacy X tools replacement
48a6faa7	2025-05-14T15:13:50	tools: Remove internal interactive-evdev This internal tool is no longer necessary, as its single special feature, `--print-modmaps`, is now available in the public `compile-keymap` tool.
ae80b244	2025-05-14T15:08:37	tools: Add --modmaps option to compile-keymap - Remove the `ENABLE_PRIVATE_APIS` guards on modmaps printing functions, since we use no private symbols. - Copy the `--print-modmaps` options from `interactive-evdev` into `compile-keymap` and rename it to `--modmaps`. This enables a feature similar to `xmodmap -pm`.
fb73f9f5	2025-05-14T15:02:24	tools: Refactor modmaps printing functions Simplify and make them print valid YAML.
2e07790e	2025-05-14T14:55:55	tools: Remove modmaps fields in interactive entries They are already printed before entering the interactive mode.
b421c2cf	2025-05-14T10:12:15	tools: Refactor compile-keymap - Use explicit input and output format - Perform more tests
af5eacea	2025-05-12T19:38:04	test: Fix uninitialized variable Warning from MSVC.

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.

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

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.

9cc19e4e

2025-08-04T22:42:34

tools: Fix missing --verbose doc + misc

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

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.

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`.

7a7a3b38

2024-02-14T09: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-19T11:24:44

test: Use explicit keymap format for test_compile_file()

56a32cc8

2025-06-18T11: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-18T11:36:07

xkbcli-interactive-wayland: Fix memory leak

69c3d257

2025-06-17T16: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

c58c7df1

2025-06-17T21:05:08

Serialize multiple actions per level to VoidAction() in v1 format When using `XKB_KEYMAP_FORMAT_TEXT_V1`, multiple actions per level are now serialized using `VoidAction()`, in order to maintain compatibility with X11.

4f2fa718

2025-06-17T16:47:20

dump: Fix typo Fixed copy-paste error. It worked for now, as both struct have the same first fields, but it is obviously semantically incorrect and not future-proof.

ee50e0c9

2025-06-12T20:14:50

keymap: Add option `unlockOnPress` for LockMods() It enables e.g. to deactivate CapsLock on press rather than on release, as in other platforms such as Windows. The specification of `LockMods()` is changed to: - On key *press*: - If `unlockOnPress` is true and some of the target modifiers were *locked* before the key press, then unlock them if `noUnlock` false. - Otherwise: - add target modifiers to *depressed* modifiers; - if `noLock` is false, add target modifiers to the *locked* modifiers. - On key *release*: - If `unlockOnPress` is true and triggered unlocking on key press, do nothing. - Otherwise: - remove modifiers from the *depressed* modifiers, if no other key that affect the same modifiers is down; - if `noUnlock` is false and if any target modifiers was locked before the key press, *unlock* them. It fixes a [12-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. [12-year old issue]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/312 [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions

d9d82355

2025-06-12T09:13:27

keymap: Add option `lockOnRelease` for LockGroup() It enables to use e.g. the combination `Control + Shift` *alone* to switch layouts, while keeping the use of `Control + Shift + other key` (typically for keyboard shortcuts). The specification of `LockGroup()` is changed to: - On key *press*: - If `lockOnRelease` is set, then key press has no effect. - Otherwise: - if the `group` is absolute, key press sets the *locked* keyboard group to `group`; - otherwise, key press adds `group` to the *locked* keyboard group. In either case, the resulting *locked* and *effective* group is brought back into range depending on the value of the `GroupsWrap` control for the keyboard. - On key *release*: - If `lockOnRelease` is not set, then key release has no effect. - Otherwise, if any other key was *pressed* after the locking key, then key release has no effect. - Otherwise, it has the same effect than a key press *without* `lockOnRelease` set. This is really useful for people coming from other platforms, such as Windows. It fixes a [20-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. [20-year old issue]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/258 [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions

c2896b32

2025-06-12T09:16:54

messages: Add new error "incompatible-keymap-text-format"

da2af4d3

2025-06-17T12:08:59

xkbcli-list: Added `layout-specific` field for options

0106b357

2025-06-17T12:06:32

registry: Add rxkb_option_is_layout_specific() Enable to query if an option accepts layout index specifiers to restrict its application to the corresponding layouts.

c4c531da

2025-06-17T11:43:50

rules: Add layout-specific options for RMLVO builder Change the signature of `xkb_rmlvo_builder_append_layout()` to accept an array of options. Also add tests for layout-specific options.

fab9d25b

2025-06-17T11:43:22

rules: Add support for layout-specific options Enabled specifying a layout index for each option, so that it applies only if the layout matches. The layout index is specified by appending immediately after the option name the `!` specifier delimiter and then the layout index, in decimal form and 1-indexed. Note that `!` was chosen instead of the usual `:` specifier delimiter, because some options contains `:`, e.g. `grp:menu_toggle`. `!` *cannot* clash with component names, because `!` is a token in the rules files and thus cannot be used as in component names. It is also vaguely similar to `:`, compared to e.g. `@` or `#`. Example: given the following rules: ! layout[any] option = symbol * opt1 = +s1:%i l2 opt2 = +s2:%i it may result in the following configurations: | Layout | Option | Symbols | | -------- | -------- | ------------ | | `l1` | `opt1` | `+s1:1` | | `l2` | `opt1` | `+s1:1` | | `l1` | `opt2` | `` | | `l2` | `opt2` | `+s2:1` | | `l1,l2` | `opt1` | `+s1:1+s1:2` | | `l1,l2` | `opt1!1` | `+s1:1` | | `l1,l2` | `opt1!2` | `+s1:2` | | `l1,l2` | `opt2` | `+s2:2` | | `l1,l2` | `opt2!1` | `` | | `l1,l2` | `opt2!2` | `+s2:2` |

52a4d9b0

2025-06-17T11:03:12

rules: Require layout or variant to enable %i expansion Before this commit, the following rule would always match: ! model = symbols * = s:%i and set symbols to `s:1`, but the `:%i` is aimed to be used only when the rules header specifies the layout or the variant. Let’s be strict and disallow matching this kind of buggy rule. Emit an error message so that we can detect it.

ef6a550f

2025-06-16T15:48:25

Add xkb_keymap_new_from_rmlvo() Use the new RMLVO builder API to compile keymaps.

da5caabb

2025-06-16T15:45:42

Add RMLVO builder API Before this commit, the API to work with RMLVO was quite minimal: it only uses raw strings from the `xkb_rule_names` struct. However: - it forces the users to deal with error-prone string formatting; - it does not enforce tying together layouts and variants; - it limits adding new features by requiring defining delimiter characters and the corresponding parsing. Added the following API: - `xkb_rmlvo_builder_new()` - `xkb_rmlvo_builder_append_layout()` - `xkb_rmlvo_builder_append_option()` - `xkb_rmlvo_builder_unref()` There is no intermediate `layout` nor `option` object, in order to to keep the API simple. The only foreseen extension is enabling configuring layout-specific options.

2906c7ec

2025-06-14T13:19:41

rules: Fix parsing group index There was a typo that made parsing hexadecimal instead of the expected decimal format.

f7a61da7

2025-06-10T17:33:24

doc: Update new layout count ranges

ac9cd053

2025-06-11T19:00:47

test: Check extended layout indexes

80b8d9d1

2025-06-10T17:34:15

dump: Adapt groups count to keymap format

62fe73cb

2025-06-10T17:33:14

parser: Raise the layout limit to 32

717ce258

2025-06-11T18:34:15

test: Refactor rules-file and state Split into dedicated functions fo better readability.

2535a3f9

2025-06-11T15:55:25

rules: Convert macros into enums & inline functions This provides semantics and better type-check.

7f39be25

2025-06-10T15:46:45

test: Use explicit keymap output format for test_compile_output()

9f3078eb

2025-06-10T15:46:31

dump: Use explicit format

0f89ad97

2025-06-09T19:26:13

dump: Always use numeric group indexes The upcoming raise of the maximum groups count will require to use numeric group indexes instead of the syntax `GroupN` if groups > 8. Let’s not bother with handling two cases (group count ≤ 8 or > 8) and always serialize group indexes as numeric values.

79e95509

2025-06-09T11:07:36

test: Use explicit keymap format in test_compile_rules()

f3386743

2025-06-09T16:44:54

test: Use explicit keymap format in test_compile_output()

2acf5eca

2025-06-09T16:26:56

test: Use explicit keymap format in test_compile_buffer()

6c5ea6fc

2025-06-09T16:15:20

test: Use explicit keymap format in test_compile_string()

6d67bce5

2025-06-08T10:01:02

doc: Towards and exhaustive compatibility page We need to track the compatibility with X11 with as much details as possible: - Transparency; - Facilitate answering issues by just pointing to the relevant page item; - Efficient reference documentation for development.

27ba56ae

2025-05-07T10:55:24

doc: Add initial documention for XKB_KEYMAP_FORMAT_TEXT_V2

44c8deb2

2025-05-07T10:20:25

Introduce keymap format v2 and make it the default for parsing - Added `XKB_KEYMAP_FORMAT_TEXT_V2`. - Made `xkb_keymap_new_from_names()` use the new keymap format. - Made the tools default to the new keymap format for input. This is in preparation for changes in the parsing & state handling. For now it changes nothing.

82ea2915

2025-05-06T17:22:22

tools: Add options to use explicit keymap format The default output keymap format is `XKB_KEYMAP_USE_ORIGINAL_FORMAT`.

62712cfe

2025-05-06T17:42:54

bench: Add options to use an explicit keymap format

08149dae

2025-05-06T16:23:04

Add internal API to query and parse supported keymap formats

58397e94

2025-05-06T18:05:30

Deprecate xkb_keymap_new_from_names() - Deprecate `xkb_keymap_new_from_names()` in favor of `xkb_keymap_new_from_names2()` - Add new changelog fragment type `deprecated`. - Change documentation to use the new function.

1a10f858

2025-05-06T18:05:06

Add xkb_keymap_new_from_names2 This is just `xkb_keymap_new_from_names()` with an explicit keymap format.

16c079d6

2025-06-06T20:27:45

chore: Rename is_absolute to is_absolute_path

39b4b670

2025-06-06T18:40:29

Support including keymap components using %-expansion and absolute path Enable to use the same `include` features than *rules* files in *keymap components*: - *`%`-expansion*: `%H` home directory, `%S` sytem root and `%E` extra. - absolute file paths. This is useful if one wants to overwrite the system file with a user config (i.e. same name, but in `~/.config/xkb`), but still include the system file: ``` // File: ~/.config/xkb/symbols/de xkb_symbols "basic" { include "%S/de(basic)" key <AB01> { [z, Z] }; key <AD06> { [y, Y] }; } ```` Without the commit, using a mere `include "de(basic)"` would result in an include loop. Refactored by using the same code for rules and keymap components.

eb0a1457

2025-06-01T18:06:59

build(deps): bump dawidd6/action-download-artifact from 9 to 10 Bumps [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) from 9 to 10. - [Release notes](https://github.com/dawidd6/action-download-artifact/releases) - [Commits](https://github.com/dawidd6/action-download-artifact/compare/v9...v10) --- updated-dependencies: - dependency-name: dawidd6/action-download-artifact dependency-version: '10' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>

16ba1af0

2025-06-01T19:51:47

ci: Fix xkeyboard-config install Since xkeyboard-config 2.45 uses a symlink for: /usr/share/pkgconfig/xkeyboard-config.pc /usr/share/X11/xkb but meson cannot overwrite < 2.45 which used a regular file and directory. Fixed by first removing the files. This is still a hack and we should use a proper package update.

bffbef88

2025-05-21T23:57:11

build: Require Bison ≥ 3.6 Older versions don’t support `%define parse.error detailed`. Fixes: a3f1a9d3ba ("xkbcomp/parser: enable Bison detailed syntax error")

7888474d

2025-05-16T14:06:18

Bump version to 1.10.0

324984f1

2025-05-17T06:49:49

xkbcomp: Fix log for unknown default field

4e1fd49a

2025-05-17T07:53:10

scripts: Enable generating new range message codes

c3744cd3

2025-05-16T14:10:37

test: Fix Compose log

9b4fd82b

2025-05-13T11:46:46

test: Skip checked arithmetic if not available

e9394b9f

2025-05-13T10:47:22

utils: Use explicit cast to prevent warnings

fb9fec18

2025-05-10T10:18:38

xkbcomp: Checked arithmetic Use a polyfill for C23 checked arithmetic. This is a bit paranoid, as we expect the user to use only 32 bit integers, so the signed 64 bit integer we use to store the result should be more than enough. Use jtckdint v1.0: - repository: https://github.com/jart/jtckdint - commit: 339450d13d8636f05dcb71ba36efddb226db481e - removed all C++-specific code

7a2aa9c9

2024-12-20T22:53:11

Always retain later Compose sequence in case of conflict This ensures that it is always possible to override previous definitions, for example when `include`ing the system Compose file. Signed-off-by: Jules Bertholet <julesbertholet@quoi.xyz>

3a8bb1a1

2025-05-16T13:13:55

compose: Fix sequence not fully overriden Previously if a new sequence did not produce a keysym or a string, the corresponding property was not overriden, possibly leaking the previous entry. - Fixed by always writting all the properties. - Also try to reuse the previous string entry, if possible, so that we avoid allocating.

9da1a2eb

2025-05-16T10:33:43

doc: Add license in generated doc

d018638d

2025-05-16T09:35:39

doc: Improve CSS

61a1e646

2025-05-15T17:24:50

doc: Reformat release notes and include them in the HTML doc

bd552642

2025-05-15T17:20:44

doc: Use custom alias to fix HTML tags unsupported by Doxygen Previous solution with `sed` is both overkilled and unreliable. Prefer a hack using Doxygen’s buit-ins, although we are not sure these are much more stable… 😓

b5f7c843

2025-05-14T21:34:23

doc: Add script to fix HTML tags unsupported by Doxygen

06fbe1b2

2025-05-14T20:08:39

doc: Promote xkbcli tools

cedc54d0

2025-05-13T15:58:52

doc: Modifier declaration and binding Detailed explanation of: - modifier declaration - real/virtual modifier maps - modifier key binding - modifier encoding - modifier portability

3eaf8ad2

2025-05-14T18:39:11

doc: Add FAQ section for legacy X tools replacement

48a6faa7

2025-05-14T15:13:50

tools: Remove internal interactive-evdev This *internal* tool is no longer necessary, as its single special feature, `--print-modmaps`, is now available in the *public* `compile-keymap` tool.

ae80b244

2025-05-14T15:08:37

tools: Add --modmaps option to compile-keymap - Remove the `ENABLE_PRIVATE_APIS` guards on modmaps printing functions, since we use no private symbols. - Copy the `--print-modmaps` options from `interactive-evdev` into `compile-keymap` and rename it to `--modmaps`. This enables a feature similar to `xmodmap -pm`.

fb73f9f5

2025-05-14T15:02:24

tools: Refactor modmaps printing functions Simplify and make them print valid YAML.

2e07790e

2025-05-14T14:55:55

tools: Remove modmaps fields in interactive entries They are already printed before entering the interactive mode.

b421c2cf

2025-05-14T10:12:15

tools: Refactor compile-keymap - Use explicit input and output format - Perform more tests

af5eacea

2025-05-12T19:38:04

test: Fix uninitialized variable Warning from MSVC.

kc3-lang/libxkbcommon

Log