Log

Author Commit Date CI Message
Pierre Le Marre 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
Pierre Le Marre 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.
Pierre Le Marre 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.
Pierre Le Marre 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
Pierre Le Marre 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
Pierre Le Marre c2896b32 2025-06-12T09:16:54 messages: Add new error "incompatible-keymap-text-format"
Pierre Le Marre 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.
Pierre Le Marre 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.
Pierre Le Marre 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` |
Pierre Le Marre 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.
Pierre Le Marre da2af4d3 2025-06-17T12:08:59 xkbcli-list: Added `layout-specific` field for options
Pierre Le Marre ef6a550f 2025-06-16T15:48:25 Add xkb_keymap_new_from_rmlvo() Use the new RMLVO builder API to compile keymaps.
Pierre Le Marre 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.
Pierre Le Marre 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.
Pierre Le Marre ac9cd053 2025-06-11T19:00:47 test: Check extended layout indexes
Pierre Le Marre 80b8d9d1 2025-06-10T17:34:15 dump: Adapt groups count to keymap format
Pierre Le Marre 62fe73cb 2025-06-10T17:33:14 parser: Raise the layout limit to 32
Pierre Le Marre f7a61da7 2025-06-10T17:33:24 doc: Update new layout count ranges
Pierre Le Marre 717ce258 2025-06-11T18:34:15 test: Refactor rules-file and state Split into dedicated functions fo better readability.
Pierre Le Marre 2535a3f9 2025-06-11T15:55:25 rules: Convert macros into enums & inline functions This provides semantics and better type-check.
Pierre Le Marre 7f39be25 2025-06-10T15:46:45 test: Use explicit keymap output format for test_compile_output()
Pierre Le Marre 9f3078eb 2025-06-10T15:46:31 dump: Use explicit format
Pierre Le Marre 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.
Pierre Le Marre f3386743 2025-06-09T16:44:54 test: Use explicit keymap format in test_compile_output()
Pierre Le Marre 2acf5eca 2025-06-09T16:26:56 test: Use explicit keymap format in test_compile_buffer()
Pierre Le Marre 6c5ea6fc 2025-06-09T16:15:20 test: Use explicit keymap format in test_compile_string()
Pierre Le Marre 79e95509 2025-06-09T11:07:36 test: Use explicit keymap format in test_compile_rules()
Pierre Le Marre 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.
Pierre Le Marre 62712cfe 2025-05-06T17:42:54 bench: Add options to use an explicit keymap format
Pierre Le Marre 08149dae 2025-05-06T16:23:04 Add internal API to query and parse supported keymap formats
Pierre Le Marre 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.
Pierre Le Marre 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.
Pierre Le Marre 27ba56ae 2025-05-07T10:55:24 doc: Add initial documention for XKB_KEYMAP_FORMAT_TEXT_V2
Pierre Le Marre 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.
Pierre Le Marre 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`.
Pierre Le Marre 16c079d6 2025-06-06T20:27:45 chore: Rename is_absolute to is_absolute_path
Pierre Le Marre 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.
dependabot[bot] 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>
Pierre Le Marre 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.
Benjamin Gilbert 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")
Pierre Le Marre 7888474d 2025-05-16T14:06:18 Bump version to 1.10.0
Pierre Le Marre 324984f1 2025-05-17T06:49:49 xkbcomp: Fix log for unknown default field
Pierre Le Marre 4e1fd49a 2025-05-17T07:53:10 scripts: Enable generating new range message codes
Pierre Le Marre c3744cd3 2025-05-16T14:10:37 test: Fix Compose log
Pierre Le Marre 9b4fd82b 2025-05-13T11:46:46 test: Skip checked arithmetic if not available
Pierre Le Marre e9394b9f 2025-05-13T10:47:22 utils: Use explicit cast to prevent warnings
Pierre Le Marre 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
Jules Bertholet 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>
Pierre Le Marre 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.
Pierre Le Marre 9da1a2eb 2025-05-16T10:33:43 doc: Add license in generated doc
Pierre Le Marre d018638d 2025-05-16T09:35:39 doc: Improve CSS
Pierre Le Marre 61a1e646 2025-05-15T17:24:50 doc: Reformat release notes and include them in the HTML doc
Pierre Le Marre 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… 😓
Pierre Le Marre b5f7c843 2025-05-14T21:34:23 doc: Add script to fix HTML tags unsupported by Doxygen
Pierre Le Marre 06fbe1b2 2025-05-14T20:08:39 doc: Promote xkbcli tools
Pierre Le Marre 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
Pierre Le Marre 3eaf8ad2 2025-05-14T18:39:11 doc: Add FAQ section for legacy X tools replacement
Pierre Le Marre 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.
Pierre Le Marre 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`.
Pierre Le Marre fb73f9f5 2025-05-14T15:02:24 tools: Refactor modmaps printing functions Simplify and make them print valid YAML.
Pierre Le Marre 2e07790e 2025-05-14T14:55:55 tools: Remove modmaps fields in interactive entries They are already printed before entering the interactive mode.
Pierre Le Marre b421c2cf 2025-05-14T10:12:15 tools: Refactor compile-keymap - Use explicit input and output format - Perform more tests
Pierre Le Marre 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.
Pierre Le Marre 61d8ec67 2025-05-12T18:20:47 misc: Fix string format specifiers Ensure better portability.
Pierre Le Marre 3031f6c3 2025-05-12T10:38:15 misc: Always use `unsigned` with `int` Better semantics & facilitate search.
Pierre Le Marre 01742b77 2025-05-12T20:40:59 misc: Ensure explicit conversion in gperf code
Pierre Le Marre b49a4409 2025-05-12T18:20:12 tools: Minor refactor of how-to-type
Pierre Le Marre 556d00a0 2025-05-12T17:52:12 keymap: Ensure proper type for layouts count
Pierre Le Marre 3bfc1bc1 2025-05-12T18:52:05 misc: Ensure proper type for darray size
Pierre Le Marre 1d361b8f 2025-05-12T10:01:10 scanner: Ensure proper type for string length
Pierre Le Marre 13e7114d 2025-05-12T09:08:49 rules: Ensure proper type of MLVO and KcCGST indexes
Pierre Le Marre ac2aa2df 2025-05-12T07:47:03 keymap: Ensure proper type for LEDs count
Pierre Le Marre 903c16da 2025-05-12T07:42:32 keymap: Ensure proper type for key types counts
Pierre Le Marre c3953a96 2025-05-12T07:37:29 keymap: Ensure proper type for key codes aliases
Pierre Le Marre 2617ebc5 2025-05-12T07:32:04 keymap: Ensure proper type for modifiers count
Pierre Le Marre 41bb797d 2025-05-12T07:31:33 symbols: Ensure proper type for keysyms count
Pierre Le Marre f7c94bfc 2025-05-12T07:08:11 symbols: Ensure proper type for levels count
Pierre Le Marre 2f4d30c2 2025-05-12T07:07:50 context: Ensure proper type for include paths count
Pierre Le Marre 10457563 2025-05-12T06:41:28 keymap: Ensure proper type for actions count
Pierre Le Marre 3911f786 2025-05-12T07:06:42 keymap: Ensure proper type for num_sym_interprets
Pierre Le Marre 8f5270c0 2025-05-12T07:07:57 utils: Improve darray - Introduce `darray_size_t` - Document struct fields: the `alloc` field may be particularly confusing
Pierre Le Marre af5eacea 2025-05-12T19:38:04 test: Fix uninitialized variable Warning from MSVC.
Pierre Le Marre 7cf3d49b 2025-05-11T18:21:07 doc: Improve actions - Improve parameters doc of supported actions - Document some legacy actions
Pierre Le Marre 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.
Pierre Le Marre 22d27277 2025-05-10T10:12:31 actions: Reject arguments if they are not expected `NoAction`, `VoidAction` and `TerminateServer` do not accept arguments.
Pierre Le Marre d239a3f0 2025-05-11T11:42:20 actions: Improve unsupported legacy X11 actions handling - Display a warning - Document drawbacks of degrading to `NoAction()`
Pierre Le Marre 137c5e90 2025-05-11T12:37:23 actions: Improve unknown action logging
Pierre Le Marre 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.
Pierre Le Marre 9191ccc9 2025-05-09T15:39:53 test: Added further case to xkb_state_update_latched_locked Test group lock wrap.
Pierre Le Marre 845d2fee 2025-05-09T16:45:36 xkbcomp: Fix affect field wrongly accepted in SetControls() action
Pierre Le Marre 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>
Pierre Le Marre 662ce937 2024-12-03T10:09:10 state: Avoid keycode lookup when key ref is available
Pierre Le Marre 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.
Pierre Le Marre 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.
Pierre Le Marre 1b402b06 2025-04-06T18:45:05 doc: Introduce the “deprecated” changelog fragment type
Pierre Le Marre 51c8c5b5 2025-05-09T00:04:42 doc: Common modifiers & LEDs names
Ran Benita 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>
Ran Benita 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>
Pierre Le Marre e00a5e83 2025-05-07T16:10:04 Add tests for pure virtual modifiers
Pierre Le Marre 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) ] }; }; };