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