kc3-lang/libxkbcommon /test/modifiers.c

Branch :

Log

Author	Commit	Date	CI	Message
	39726cac	2025-08-06 20:29:26		Add xkb_keymap_mod_get_mask2() Retrospectively, `xkb_keymap_mod_get_mask()` should have used a modifier index rather that a modifier name in its type. Since we already published a version with this API, it’s too late to change that, so instead add a new function `xkb_keymap_mod_get_mask2()`.
	84914512	2025-07-01 18:37:22		chore: Rename indexes to indices Before this commit there was a mix between the two forms. While “indexes” is correct, “indices” is more usual and also the historical form used in this project.
	7a7a3b38	2024-02-14 09:47:15		keymap: Canonically map unmapped virtual modifiers Traditionally, virtual modifiers were merely name aliases for real modifiers (X core modifiers), e.g. `NumLock` was usually mapped to `Mod2` (see `modifier_map` statement). Virtual modifiers that were never mapped to a real ones had no effect on the keymap state. xkbcommon already supports the concept of “pure” virtual modifiers, i.e. virtual modifiers that are encoded using the full 32-bit range, not just the first 8 bits corresponding to the real modifiers. But until this commit, one had to declare such mapping explicitly: e.g. `virtual_modifiers M = 0x100;`. This has at least two drawbacks: - Numerical values may look quite arbitrary and are not user-friendly. It’s OK in the resulting compiled keymap, but it requires careful sync between sections when developing KcCGST files. - If the modifier is also mapped implicitly using the traditional `vmodmap`/`modifier_map`, then both mappings are OR-combined. This patch enables to automatically map unmapped virtual modifiers to their canonical mapping, i.e. themselves: their corresponding virtual and real modifier masks are identical: `1u << mod_index`. Since this feature is incompatible with X11, this is guarded by requiring at least keymap text format v2. Note that for now, canonical virtual modifiers cannot be used in an interpret action’s `AnyOf()`. An interpret action for a canonical virtual modifier must be `AnyOfOrNone()` to take effect: virtual_modifiers APureMod, …; interpret a+AnyOfOrNone(all) { virtualModifier= APureMod; action= SetMods(modifiers=APureMod); }; The above adds a virtual modifier `APureMod` for keysym `a`. It will be canonical iff it is not mapped implicitly.
	d351abee	2025-06-19 11:24:44		test: Use explicit keymap format for test_compile_file()
	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()
	3031f6c3	2025-05-12 10:38:15		misc: Always use `unsigned` with `int` Better semantics & facilitate search.
	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.
	e00a5e83	2025-05-07 16:10:04		Add tests for pure virtual modifiers
	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.
	f8148744	2025-05-06 11: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.
	e120807b	2025-01-29 15:35:22		Update license notices to SDPX short identifiers + update LICENSE Fix #628. Signed-off-by: Ran Benita <ran@unusedvar.com>
	c7fdf506	2025-01-16 20:23:28		Use portable integer literal suffixes
	2ba9daf1	2024-09-23 16:20:37		mods: Add more built-in names Added support for the following virtual modifiers: - `Alt` - `Meta` - `NumLock` - `Super` - `Hyper` - `LevelThree` - `LevelFive` - `ScrollLock`
	086a286a	2024-09-23 16:20:17		mods: Always use constants from xkbcommon-names.h Respect the claim that real modifiers names are built-in: - Add `XKB_MOD_NAME_MOD[1-5]` constants. - Replace modifiers names with their corresponding constants.
	e325e65e	2024-02-20 08:13:37		Add test_unit to all tests Currently it only ensure we do not buffer `stdout`.
	5b5b67f2	2023-05-01 22:30:41		Add support for modmap None (#291) Unlike current xkbcommon, X11’s xkbcomp allows to remove entries in the modifiers’ map using “modifier_map None { … }”. “None” is translated to the special value “XkbNoModifier” defined in “X11/extensions/XKB.h”. Then it relies on the fact that in "CopyModMapDef", the following code: 1U << entry->modifier ends up being zero when “entry->modifier” is “XkbNoModifier” (i.e. 0xFF). Indeed, it relies on the overflow behaviour of the left shift, which in practice resolves to use only the 5 low bits of the shift amount, i.e. 0x1F here. Then the result of “1U << 0xFF” is cast to “char”, i.e. 0. This is a good trick but too magical, so in libxkbcommon we will use an explicit test against our new constant XKB_MOD_NONE.