kmx git

Commit	Date	Message
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.
ac9cd053	2025-06-11T19:00:47	test: Check extended layout indexes
80b8d9d1	2025-06-10T17:34:15	dump: Adapt groups count to keymap format
f7a61da7	2025-06-10T17:33:24	doc: Update new layout count ranges
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.
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()
79e95509	2025-06-09T11:07:36	test: Use explicit keymap format in test_compile_rules()
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
c3744cd3	2025-05-16T14:10:37	test: Fix Compose log
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
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
2617ebc5	2025-05-12T07:32:04	keymap: Ensure proper type for modifiers count
41bb797d	2025-05-12T07:31:33	symbols: Ensure proper type for keysyms count
f7c94bfc	2025-05-12T07:08:11	symbols: Ensure proper type for levels count
2f4d30c2	2025-05-12T07:07:50	context: Ensure proper type for include paths count
10457563	2025-05-12T06:41:28	keymap: Ensure proper type for actions count
3911f786	2025-05-12T07:06:42	keymap: Ensure proper type for num_sym_interprets
8f5270c0	2025-05-12T07:07:57	utils: Improve darray - Introduce `darray_size_t` - Document struct fields: the `alloc` field may be particularly confusing
af5eacea	2025-05-12T19:38:04	test: Fix uninitialized variable Warning from MSVC.
72ed9104	2025-05-12T19:29:24	test: Use standard C rather than POSIX API Windows does not use the same functions signatures and generates a lot of warnings.
61d8ec67	2025-05-12T18:20:47	misc: Fix string format specifiers Ensure better portability.
3031f6c3	2025-05-12T10:38:15	misc: Always use `unsigned` with `int` Better semantics & facilitate search.
01742b77	2025-05-12T20:40:59	misc: Ensure explicit conversion in gperf code
b49a4409	2025-05-12T18:20:12	tools: Minor refactor of how-to-type
556d00a0	2025-05-12T17:52:12	keymap: Ensure proper type for layouts count
3bfc1bc1	2025-05-12T18:52:05	misc: Ensure proper type for darray size
1d361b8f	2025-05-12T10:01:10	scanner: Ensure proper type for string length
13e7114d	2025-05-12T09:08:49	rules: Ensure proper type of MLVO and KcCGST indexes
ac2aa2df	2025-05-12T07:47:03	keymap: Ensure proper type for LEDs count
903c16da	2025-05-12T07:42:32	keymap: Ensure proper type for key types counts
c3953a96	2025-05-12T07:37:29	keymap: Ensure proper type for key codes aliases
7cf3d49b	2025-05-11T18:21:07	doc: Improve actions - Improve parameters doc of supported actions - Document some legacy actions
9951184e	2025-05-10T10:15:54	actions: Properly reset type to NoAction on error If we do not reset the type, the action may lready have been initialized to with a default action and thus will not be ignored.
22d27277	2025-05-10T10:12:31	actions: Reject arguments if they are not expected `NoAction`, `VoidAction` and `TerminateServer` do not accept arguments.
d239a3f0	2025-05-11T11:42:20	actions: Improve unsupported legacy X11 actions handling - Display a warning - Document drawbacks of degrading to `NoAction()`
137c5e90	2025-05-11T12:37:23	actions: Improve unknown action logging
b4c89600	2025-05-09T15:15:10	actions: Add VoidAction(), mirroring NoSymbol/VoidSymbol. Added `VoidAction()` action to match the keysym pair `NoSymbol` / `VoidSymbol`. It enables overriding a previous action and breaks latches. This is a libxkbcommon extension. When serializing it will be converted to `LockControls(controls=none,affect=neither)` for backward compatibility. We cannot serialize it to `NoAction()`, as it would be dropped in e.g. the context of multiple actions.
9191ccc9	2025-05-09T15:39:53	test: Added further case to xkb_state_update_latched_locked Test group lock wrap.
845d2fee	2025-05-09T16:45:36	xkbcomp: Fix affect field wrongly accepted in SetControls() action
551cca2a	2024-12-03T10:12:03	state: Add server API for updating latched and locked mods & layout Up to now, the “server state” `xkb_state` API only offered one entry point to update the server state – `xkb_state_update_key`, which reflects the direct keyboard keys state. But some updates come out-of-band from keyboard input events stream, for example, a GUI layout switcher. The X11 XKB protocol has a request which allows for such updates, `XkbLatchLockState`[^1], but xkbcommon does not have similar functionality. So server applications ended up using `xkb_state_update_state` for this, but that’s a function intended for client applications, not servers. Add support for updating the latched & locked state of the mods and layout. Note that the depressed states cannot be updated in this way -- XKB does not expect them to be updated out of band. [^1]: https://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#Querying_and_Changing_Keyboard_State Fixes: #310 Signed-off-by: Ran Benita <ran@unusedvar.com> Co-authored-by: Ran Benita <ran@unusedvar.com> Co-authored-by: Pierre Le Marre <dev@wismill.eu>
662ce937	2024-12-03T10:09:10	state: Avoid keycode lookup when key ref is available
7cd1180b	2025-05-06T11:07:47	modifiers: Add xkb_keymap_mod_get_mask() Added a dedicated API to query modifier masks rather than relying on a hack using `xkb_state_update_mask` and `xkb_state_serialize_mods`. Furthermore, this hack may not work in the future if we remove virtual mods resolution in `xkb_state_update_mask` to avoid corner-cases issues.
9fab3948	2025-05-09T00:05:31	doc: Deprecate legacy modifiers names The following modifiers names in `xkbcommon/xkbcommon-names.h` are now deprecated: - `XKB_MOD_NAME_ALT`: use `XKB_VMOD_NAME_ALT` instead. - `XKB_MOD_NAME_LOGO`: use `XKB_VMOD_NAME_SUPER` instead. - `XKB_MOD_NAME_NUM`: use `XKB_VMOD_NAME_NUM` instead.
1b402b06	2025-04-06T18:45:05	doc: Introduce the “deprecated” changelog fragment type
51c8c5b5	2025-05-09T00:04:42	doc: Common modifiers & LEDs names
a3f1a9d3	2025-02-04T20:45:38	xkbcomp/parser: enable Bison detailed syntax error It's not much, but instead of xkbcommon: ERROR: [XKB-769] (unknown file):5:25: syntax error we get xkbcommon: ERROR: [XKB-769] (unknown file):5:25: syntax error, unexpected +, expecting INTEGER which is at least a little helpful. Signed-off-by: Ran Benita <ran@unusedvar.com>
e6aec067	2025-04-29T17:14:01	build: drop support for byacc It doesn't support `%define parse.error detailed` which we want to use. If needed, we can probably bring back support using some macro hackery. Signed-off-by: Ran Benita <ran@unusedvar.com>
e00a5e83	2025-05-07T16:10:04	Add tests for pure virtual modifiers
c2d3694b	2025-05-06T07:01:01	xkbcomp: Do not discard extra bits in vmod masks Since we accept numeric values for the vmod mask in the keymap, we may have extra bits set that encode no real/virtual modifier. Keep them unchanged for consistency. E.g. the following keymap: xkb_keymap { xkb_keycodes { <a> = 38; }; xkb_symbols { virtual_modifiers X = 0xf0000000; key <a> { [ SetMods(mods = 0x00001100) ] }; }; }; would compile to: xkb_keymap { xkb_keycodes { <a> = 38; }; xkb_symbols { virtual_modifiers X = 0xf0000000; // Internal state key <a> { [ SetMods(mods = 0xf0001000) ] }; // Serialization key <a> { [ SetMods(mods = 0x00001100) ] }; }; };
dddffd51	2025-05-05T13:22:57	state: Fix virtual modifiers with non-real mod mapping Currently there are 2 issues with the handling of virtual modifiers in the keyboard state: 1. We assume that the input modifiers masks encode the indexes of all the modifiers of the keymap, but this is true only for the real modifiers (at least in xkbcommon and X11). Indeed, since the virtual modifiers indexes are implementation-specific, the input modifier masks merely encode the modifiers via their mapping. Consider the following keymap: ```c xkb_keymap { xkb_compat { virtual_modifiers M1 = 0x100; }; xkb_types { virtual_modifiers M2 = 0x200; }; }; ``` Now to illustrate, consider the following 2 implementation variants of libxkbcommon (assuming indexes 0-7 are the usual real modifiers): 1. Process `xkb_compat` then `xkb_types`. M1 and M2 have the respective indexes 8 and 9 and map to themselves (with the current assumption about mask denotation). 2. Process `xkb_types` then `xkb_compat`. M1 and M2 have the respective indexes 9 and 8 and map to each other. With the current `xkb_state_update_mask`, implementation 2 will swap M1 and M2 (compared to impl. 1) at each update! Indeed, we can see that `xkb_state_serialize_mods` doesn’t roundtrip via `xkb_state_update_mask`. 2. We assume that modifier masks use only bits denoting modifiers in the keymap, but when parsing the keymap we accept explicit virtual modifiers mapping of arbitrary values. E.g. if `M1` is the only virtual modifier and it is defined by: ```c virtual_modifiers M1 = 0x80000000; // 1 << (32 - 1) ``` then the 32th bit of a modifier mask input does not denote the 32th virtual modifier of the keymap, but merely the encoding of the mapping of `M1`. So when calling `xkb_state_update_mask`, we may discard some bits of the modifiers masks and end up with an incorrect state. These 2 issues may break interoperability with other implementations of XKB (e.g. kbvm) and make pure virtual modifiers handling fragile. We introduce the notion of canonical state modifier mask: the mask with the smallest population count that denotes all bits used to encode the modifiers in the keyboard state. It is equal to the bitwise OR of real modifiers mask and all the virtual modifiers mappings. This commit fixes the 2 issues by making weaker assumptions about the input modifier masks: 1. Modifiers may map to arbitrary values, not only real modifiers. 2. Input modifier masks merely encode modifiers via their mapping: - real modifiers map to themselves; - virtual modifiers map to the bitwise OR of their explicit mapping (via `virtual_modifiers`) and their implicit mapping (via keys’ real and virtual modmaps). - modifiers indexes are implementation-specific. Since the implementation before this commit also resolved virtual modifiers to their mappings, we continue doing so, but using only the bits that are not set in the canonical state modifier mask, so that we enable roundtrip of `xkb_state_serialize_mods` via `xkb_state_update_mask`. 3. Input modifier masks do not denote modifiers indexes (apart from real modifiers), so it is safe to discard only the bits that are not set in the canonical state modifier mask.
dd642359	2025-05-07T00:06:10	Bump version to 1.9.2
d5b779e1	2025-05-06T21:07:28	keymap: Fix empty compat interpretation map serialization X11’s `xkbcomp` requires at least one compat interpretation entry.
87f9ac76	2025-05-06T21:02:23	keymap: Fix empty compat interpretation statement serialization Statements such as `interpret VoidSymbol {};` can cannot be parsed by X11’s `xkbcomp`. Fixed by using a dummy action.
ac42ce29	2025-05-06T21:29:46	test: Check xkeyboard-config xkbcommon → xkbcomp chaining
230b6a6a	2025-05-06T14:35:26	Fix key type map entry with unbound vmod not ignored Currently we only ignore key type map entries with non-zero mods and with a zero modifier mask. However, the XKB protocol states ([source]): > Map entries which specify unbound virtual modifiers are not considered. So we currently handle `map[Unbound]` key type map entries (all modifiers unbound) but not `map[Bound+Unbound]` entries (mix of bound and unbound modifiers). Fixed by properly checking unbound modifiers on each key type map entry. This also fixes a test that was accidentally passing. [source]: https://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#:~:text=Map%20entries%20which%20specify%20unbound%20virtual%20modifiers,not%20considered
f8148744	2025-05-06T11:26:21	Define the mapping of real modifiers explicitly When querying for a modifier mapping, we should treat all modifiers equally. So simply store real modifier mapping as we do for the virtual ones. Also fixed useless boolean conversions.
e1aca42e	2025-05-05T12:06:18	state: Minor refactor - Move variable declaration close to their use. - Make them constant whenever possible.
8bc60ee3	2025-05-05T13:20:45	modifiers: Minor optimization It has low impact, but it also adds better semantics.
7df431ac	2025-05-02T19:44:15	Bump version to 1.9.1
cd512b8f	2025-05-02T19:21:09	x11: Fix capitalization transformation
9ffe3cfc	2025-04-29T12:48:10	doc: Create a FAQ page - Initialize with multiple recurrent questions. - Document how to get the vmod → rmod mapping. Rational: Some applications may need it to interface with legacy code.

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.

ac9cd053

2025-06-11T19:00:47

test: Check extended layout indexes

80b8d9d1

2025-06-10T17:34:15

dump: Adapt groups count to keymap format

f7a61da7

2025-06-10T17:33:24

doc: Update new layout count ranges

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.

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()

79e95509

2025-06-09T11:07:36

test: Use explicit keymap format in test_compile_rules()

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

c3744cd3

2025-05-16T14:10:37

test: Fix Compose log

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

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

2617ebc5

2025-05-12T07:32:04

keymap: Ensure proper type for modifiers count

41bb797d

2025-05-12T07:31:33

symbols: Ensure proper type for keysyms count

f7c94bfc

2025-05-12T07:08:11

symbols: Ensure proper type for levels count

2f4d30c2

2025-05-12T07:07:50

context: Ensure proper type for include paths count

10457563

2025-05-12T06:41:28

keymap: Ensure proper type for actions count

3911f786

2025-05-12T07:06:42

keymap: Ensure proper type for num_sym_interprets

8f5270c0

2025-05-12T07:07:57

utils: Improve darray - Introduce `darray_size_t` - Document struct fields: the `alloc` field may be particularly confusing

af5eacea

2025-05-12T19:38:04

test: Fix uninitialized variable Warning from MSVC.

72ed9104

2025-05-12T19:29:24

test: Use standard C rather than POSIX API Windows does not use the same functions signatures and generates a lot of warnings.

61d8ec67

2025-05-12T18:20:47

misc: Fix string format specifiers Ensure better portability.

3031f6c3

2025-05-12T10:38:15

misc: Always use `unsigned` with `int` Better semantics & facilitate search.

01742b77

2025-05-12T20:40:59

misc: Ensure explicit conversion in gperf code

b49a4409

2025-05-12T18:20:12

tools: Minor refactor of how-to-type

556d00a0

2025-05-12T17:52:12

keymap: Ensure proper type for layouts count

3bfc1bc1

2025-05-12T18:52:05

misc: Ensure proper type for darray size

1d361b8f

2025-05-12T10:01:10

scanner: Ensure proper type for string length

13e7114d

2025-05-12T09:08:49

rules: Ensure proper type of MLVO and KcCGST indexes

ac2aa2df

2025-05-12T07:47:03

keymap: Ensure proper type for LEDs count

903c16da

2025-05-12T07:42:32

keymap: Ensure proper type for key types counts

c3953a96

2025-05-12T07:37:29

keymap: Ensure proper type for key codes aliases

7cf3d49b

2025-05-11T18:21:07

doc: Improve actions - Improve parameters doc of supported actions - Document some legacy actions

9951184e

2025-05-10T10:15:54

actions: Properly reset type to NoAction on error If we do not reset the type, the action may lready have been initialized to with a default action and thus will not be ignored.

22d27277

2025-05-10T10:12:31

actions: Reject arguments if they are not expected `NoAction`, `VoidAction` and `TerminateServer` do not accept arguments.

d239a3f0

2025-05-11T11:42:20

actions: Improve unsupported legacy X11 actions handling - Display a warning - Document drawbacks of degrading to `NoAction()`

137c5e90

2025-05-11T12:37:23

actions: Improve unknown action logging

b4c89600

2025-05-09T15:15:10

actions: Add VoidAction(), mirroring NoSymbol/VoidSymbol. Added `VoidAction()` action to match the keysym pair `NoSymbol` / `VoidSymbol`. It enables overriding a previous action and breaks latches. This is a libxkbcommon extension. When serializing it will be converted to `LockControls(controls=none,affect=neither)` for backward compatibility. We cannot serialize it to `NoAction()`, as it would be dropped in e.g. the context of multiple actions.

9191ccc9

2025-05-09T15:39:53

test: Added further case to xkb_state_update_latched_locked Test group lock wrap.

845d2fee

2025-05-09T16:45:36

xkbcomp: Fix affect field wrongly accepted in SetControls() action

551cca2a

2024-12-03T10:12:03

state: Add server API for updating latched and locked mods & layout Up to now, the “server state” `xkb_state` API only offered one entry point to update the server state – `xkb_state_update_key`, which reflects the direct keyboard keys state. But some updates come out-of-band from keyboard input events stream, for example, a GUI layout switcher. The X11 XKB protocol has a request which allows for such updates, `XkbLatchLockState`[^1], but xkbcommon does not have similar functionality. So server applications ended up using `xkb_state_update_state` for this, but that’s a function intended for client applications, not servers. Add support for updating the latched & locked state of the mods and layout. Note that the depressed states cannot be updated in this way -- XKB does not expect them to be updated out of band. [^1]: https://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#Querying_and_Changing_Keyboard_State Fixes: #310 Signed-off-by: Ran Benita <ran@unusedvar.com> Co-authored-by: Ran Benita <ran@unusedvar.com> Co-authored-by: Pierre Le Marre <dev@wismill.eu>

662ce937

2024-12-03T10:09:10

state: Avoid keycode lookup when key ref is available

7cd1180b

2025-05-06T11:07:47

modifiers: Add xkb_keymap_mod_get_mask() Added a dedicated API to query modifier masks rather than relying on a hack using `xkb_state_update_mask` and `xkb_state_serialize_mods`. Furthermore, this hack may not work in the future if we remove virtual mods resolution in `xkb_state_update_mask` to avoid corner-cases issues.

9fab3948

2025-05-09T00:05:31

doc: Deprecate legacy modifiers names The following modifiers names in `xkbcommon/xkbcommon-names.h` are now deprecated: - `XKB_MOD_NAME_ALT`: use `XKB_VMOD_NAME_ALT` instead. - `XKB_MOD_NAME_LOGO`: use `XKB_VMOD_NAME_SUPER` instead. - `XKB_MOD_NAME_NUM`: use `XKB_VMOD_NAME_NUM` instead.

1b402b06

2025-04-06T18:45:05

doc: Introduce the “deprecated” changelog fragment type

51c8c5b5

2025-05-09T00:04:42

doc: Common modifiers & LEDs names

a3f1a9d3

2025-02-04T20:45:38

xkbcomp/parser: enable Bison detailed syntax error It's not much, but instead of xkbcommon: ERROR: [XKB-769] (unknown file):5:25: syntax error we get xkbcommon: ERROR: [XKB-769] (unknown file):5:25: syntax error, unexpected +, expecting INTEGER which is at least a little helpful. Signed-off-by: Ran Benita <ran@unusedvar.com>

e6aec067

2025-04-29T17:14:01

build: drop support for byacc It doesn't support `%define parse.error detailed` which we want to use. If needed, we can probably bring back support using some macro hackery. Signed-off-by: Ran Benita <ran@unusedvar.com>

e00a5e83

2025-05-07T16:10:04

Add tests for pure virtual modifiers

c2d3694b

2025-05-06T07:01:01

xkbcomp: Do not discard extra bits in vmod masks Since we accept numeric values for the vmod mask in the keymap, we may have extra bits set that encode *no* real/virtual modifier. Keep them unchanged for consistency. E.g. the following keymap: xkb_keymap { xkb_keycodes { <a> = 38; }; xkb_symbols { virtual_modifiers X = 0xf0000000; key <a> { [ SetMods(mods = 0x00001100) ] }; }; }; would compile to: xkb_keymap { xkb_keycodes { <a> = 38; }; xkb_symbols { virtual_modifiers X = 0xf0000000; // Internal state key <a> { [ SetMods(mods = 0xf0001000) ] }; // Serialization key <a> { [ SetMods(mods = 0x00001100) ] }; }; };

dddffd51

2025-05-05T13:22:57

state: Fix virtual modifiers with non-real mod mapping Currently there are 2 issues with the handling of virtual modifiers in the keyboard state: 1. We assume that the input modifiers masks encode the indexes of all the modifiers of the keymap, but this is true only for the *real* modifiers (at least in xkbcommon and X11). Indeed, since the virtual modifiers *indexes* are implementation-specific, the input modifier masks merely *encode* the modifiers via their *mapping*. Consider the following keymap: ```c xkb_keymap { xkb_compat { virtual_modifiers M1 = 0x100; }; xkb_types { virtual_modifiers M2 = 0x200; }; }; ``` Now to illustrate, consider the following 2 implementation variants of libxkbcommon (assuming indexes 0-7 are the usual real modifiers): 1. Process `xkb_compat` then `xkb_types`. M1 and M2 have the respective indexes 8 and 9 and map to themselves (with the current assumption about mask denotation). 2. Process `xkb_types` then `xkb_compat`. M1 and M2 have the respective indexes 9 and 8 and map to each other. With the current `xkb_state_update_mask`, implementation 2 will swap M1 and M2 (compared to impl. 1) at each update! Indeed, we can see that `xkb_state_serialize_mods` doesn’t roundtrip via `xkb_state_update_mask`. 2. We assume that modifier masks use only bits denoting modifiers in the keymap, but when parsing the keymap we accept explicit virtual modifiers mapping of arbitrary values. E.g. if `M1` is the only virtual modifier and it is defined by: ```c virtual_modifiers M1 = 0x80000000; // 1 << (32 - 1) ``` then the 32th bit of a modifier mask input does *not* denote the 32th virtual modifier of the keymap, but merely the encoding of the mapping of `M1`. So when calling `xkb_state_update_mask`, we may discard some bits of the modifiers masks and end up with an incorrect state. These 2 issues may break interoperability with other implementations of XKB (e.g. kbvm) and make pure virtual modifiers handling fragile. We introduce the notion of *canonical state modifier mask*: the mask with the smallest population count that denotes all bits used to encode the modifiers in the keyboard state. It is equal to the bitwise OR of real modifiers mask and all the virtual modifiers mappings. This commit fixes the 2 issues by making *weaker* assumptions about the input modifier masks: 1. Modifiers may map to arbitrary values, not only real modifiers. 2. Input modifier masks merely encode modifiers via their *mapping*: - *real* modifiers map to themselves; - *virtual* modifiers map to the bitwise OR of their *explicit* mapping (via `virtual_modifiers`) and their *implicit* mapping (via keys’ real and virtual modmaps). - modifiers indexes are implementation-specific. Since the implementation before this commit also resolved virtual modifiers to their mappings, we continue doing so, but using only the bits that are *not* set in the canonical state modifier mask, so that we enable roundtrip of `xkb_state_serialize_mods` via `xkb_state_update_mask`. 3. Input modifier masks do not denote modifiers indexes (apart from real modifiers), so it is safe to discard only the bits that are not set in the canonical state modifier mask.

dd642359

2025-05-07T00:06:10

Bump version to 1.9.2

d5b779e1

2025-05-06T21:07:28

keymap: Fix empty compat interpretation map serialization X11’s `xkbcomp` requires at least one compat interpretation entry.

87f9ac76

2025-05-06T21:02:23

keymap: Fix empty compat interpretation statement serialization Statements such as `interpret VoidSymbol {};` can cannot be parsed by X11’s `xkbcomp`. Fixed by using a dummy action.

ac42ce29

2025-05-06T21:29:46

test: Check xkeyboard-config xkbcommon → xkbcomp chaining

230b6a6a

2025-05-06T14:35:26

Fix key type map entry with unbound vmod not ignored Currently we only ignore key type map entries with non-zero mods and with a zero modifier mask. However, the XKB protocol states ([source]): > Map entries which specify unbound virtual modifiers are not considered. So we currently handle `map[Unbound]` key type map entries (all modifiers unbound) but not `map[Bound+Unbound]` entries (mix of bound and unbound modifiers). Fixed by properly checking unbound modifiers on each key type map entry. This also fixes a test that was accidentally passing. [source]: https://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#:~:text=Map%20entries%20which%20specify%20unbound%20virtual%20modifiers,not%20considered

f8148744

2025-05-06T11:26:21

Define the mapping of real modifiers explicitly When querying for a modifier mapping, we should treat all modifiers equally. So simply store real modifier mapping as we do for the virtual ones. Also fixed useless boolean conversions.

e1aca42e

2025-05-05T12:06:18

state: Minor refactor - Move variable declaration close to their use. - Make them constant whenever possible.

8bc60ee3

2025-05-05T13:20:45

modifiers: Minor optimization It has low impact, but it also adds better semantics.

7df431ac

2025-05-02T19:44:15

Bump version to 1.9.1

cd512b8f

2025-05-02T19:21:09

x11: Fix capitalization transformation

9ffe3cfc

2025-04-29T12:48:10

doc: Create a FAQ page - Initialize with multiple recurrent questions. - Document how to get the vmod → rmod mapping. Rational: Some applications may need it to interface with legacy code.

kc3-lang/libxkbcommon

Log