kc3-lang/libxkbcommon/test/keyseq.c
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
447b7739 | 2025-06-22 10:27:31 | test: Add examples for breaking latches using VoidAction() Consider the following use cases: 1. If `Caps_Lock` is on the second level of some key, and `Shift` is latched, pressing the key locks `Caps` while also breaking the `Shift` latch, ensuring that the next character is properly uppercase. 2. On the German E1 layout, `ISO_Level5_Latch` is on the third level of `<AC04>`. So if a level 3 latch is used to access it, the level 5 must break the previous level 3 latch, else both latches would be active: the effective level would be 7 instead of the intended 5. Both uses cases can be implemented using existing features: - multiple actions per level; - `VoidAction()`: to break latches. | |
|
c4f4ba41 | 2025-06-23 18:15:18 | state: Fix modifier and group latch Prior to this commit, the sequences: - 1. latch A ↓ 2. latch B ↓ 3. latch B ↑ 4. latch A ↑ - 1. latch A ↓ 2. latch B ↓ 3. latch A ↑ 4. latch B ↑ would result in only B being latched, because the XKB protocol specifies that latches are triggered only if keys are *sequentially* tapped, i.e. a strict sequence of press and release of each key. It seems an unnecessary limitation: - `SlowKeys` and `XkbAX_TwoKeys` are the proper accessibility features to control accidental key presses, not latches nor `StickyKeys`. - Latches are also used outside their original accessibility role. A user may activate multiple latch keys simultaneously: - same hand: two latch keys being close to each other; - different hand: two keys being activated independently. Changed the latching behavior so that the rules used to break a latch are the same than those used to prevent it. Depressing and releasing two latching keys simultaneously will now activate both latches, as expected. Since this is a breaking change, it is enabled only by the keymap format `XKB_KEYMAP_FORMAT_TEXT_V2`. | |
|
d192b3b6 | 2025-06-19 21:57:46 | keymap: Add option `unlockOnPress` for SetMods() It enables e.g. to deactivate `CapsLock` *on press* rather than on release, as in other platforms such as Windows. It fixes a [18-year old issue] inherited from the X11 ecosystem, by extending the [XKB protocol key actions]. As it is incompatible with X11, this feature is available only using the keymap text format v2. [18-year old issue]: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/74 [XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions | |
|
d351abee | 2025-06-19 11:24:44 | test: Use explicit keymap format for test_compile_file() | |
|
69c3d257 | 2025-06-17 16: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 | |
|
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 | |
|
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 | |
|
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. | |
|
e00a5e83 | 2025-05-07 16:10:04 | Add tests for pure virtual modifiers | |
 |
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> | |
|
af5704dc | 2025-01-25 11:01:03 | state: Fix empty level not breaking latches In essence empty levels are levels with just a `NoSymbol` keysym and a `NoAction()`, which breaks latches. Fixed regression introduced in fdf2c525977e7e8af4135d593110f5bc1454abd8. Added tests also for the case where the keycode is unknown. | |
|
7a08b145 | 2025-01-24 11:10:17 | tests: Modifier and group latch - Added a big bunch of tests for modifier latch. No yet exhaustive, but should cover the most usual use cases. - Added missing test cases for breaking the group latch. Ideally, more tests should be added to match the coverage of modifiers latches. WARNING: it is ambiguous what prevents a latch when multiple keys are *simultenously* operated together. We currently assuming that any action that is not identical to the considered latch prevents it. | |
|
c7fdf506 | 2025-01-16 20:23:28 | Use portable integer literal suffixes | |
 |
3fdd822d | 2025-01-16 02:21:29 | state: Fix mods not being independently cleared (#584) The modifiers filters should ensure minimal interaction between them, but currently the Latch mod filters are overzealous and mess with the mods from other filters set to be cleared, resulting in some modifiers permanently set. Fixed by clearing mods properly with `OR` rather than direct setting of `state::clear_mods`. While we are at it, `state::set_mods` should be `OR`ed as well. This should not have any impact for now, but this is more future-proof. Fixes #583 Co-authored-by: Jules Bertholet <julesbertholet@quoi.xyz> Co-authored-by: Pierre Le Marre <dev@wismill.eu> | |
|
6c6dbf32 | 2025-01-07 11:19:30 | state: Fix LatchGroup action with latchToLock disabled A `LatchGroup` action with the `latchToLock`` option disabled can apply its latch effect multiple times. | |
|
948f7a59 | 2024-10-09 08:34:27 | symbols: Skip interprets only for groups with explicit actions Previously setting explicit actions for a group in symbols files made the parser skip compatibility interpretations for the corresponding *whole* key, so the other groups with *no* explicit actions could result broken on some levels. In the following example, `<RALT>` would have an action on group 2, because it is explicit, but none on group 1 because interpretation are also skipped there as a side effect: ```c key <RALT> { symbols[1]= [ ISO_Level3_Shift ], symbols[2]= [ ISO_Level3_Shift ], actions[2]= [ SetMods(modifiers=LevelThree) ] }; ``` Fixed by skipping interpretations *only* for groups with explicit actions. We still set `key->explicit |= EXPLICIT_INTERP` if at least one group has explicit actions. In such case, when dumping a keymap, we will write explicit actions for *all* groups, in order to ensure that X11 and previous versions of libxkbcommon can parse the keymap as intended. One side effect is that no interpretation will be run on this key anymore, so we may have to set some extra fields explicitly: repeat, virtualMods. Thus the previous example would be bumped as: ```c key <RALT> { repeat= No, symbols[1]= [ ISO_Level3_Shift ], actions[1]= [ SetMods(modifiers=LevelThree,clearLocks) ], symbols[2]= [ ISO_Level3_Shift ], actions[2]= [ SetMods(modifiers=LevelThree) ] }; ``` | |
|
e9bd7de4 | 2024-07-04 16:22:13 | state: Add support for group latch action Surprisingly, the latch group action was not yet implemented. Added tests to ensure we get the tricky bits right. | |
|
e325e65e | 2024-02-20 08:13:37 | Add test_unit to all tests Currently it only ensure we do not buffer `stdout`. | |
 |
51e08472 | 2024-02-14 11:29:19 | Fix a typo | |
|
40aab05e | 2019-12-27 13:03:20 | build: include config.h manually Previously we included it with an `-include` compiler directive. But that's not portable. And it's better to be explicit anyway. Every .c file should have `include "config.h"` first thing. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
 |
6456835f | 2017-12-03 13:04:35 | test/data: sync with xkeyboard-config 2.22 Some tweaks to the de(neo) keyseq tests were required. It seems to have improved. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a0d2b029 | 2014-10-17 01:14:57 | test/keyseq: test 'map[None] = Level2;' scenario See previous commit for an explanation. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
24846080 | 2014-09-11 14:08:12 | test/keyseq: add test Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
ba985629 | 2014-09-06 11:29:15 | test: make most tests portable by copying linux/input.h locally There is really no reason to deny these tests from different platforms only for a few #defines. The only linux-only test (or test program, it is not run by make check) is interactive-evdev, which actually uses evdev. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
7f1b7a1c | 2013-07-25 13:21:33 | test/keyseq: add de(neo) Level{6,7,8} tests Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
0c8e9e0c | 2013-07-22 18:43:53 | test: sync test/data from xkeyboard-config 2.9 Needed for some tests. The tests need some adjustment, mostly because of the resolution of xkeyboard-config bug https://bugs.freedesktop.org/show_bug.cgi?id=50935 Also add the 'ch' symbols file for future tests. Signed-off-by: Ran Benita <ran234@gmail.com> | |
 |
54f95f49 | 2013-03-18 21:02:35 | test: Add flags argument to test_get_context() Allowing overriding of environment suppression, at first. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
a1f203c0 | 2013-03-18 20:55:18 | test: Move test_key_seq to common.c Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
559252a1 | 2013-03-08 16:31:33 | keyseq: add a couple of tests Tests the filter refcounting. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
089c3a18 | 2013-02-17 14:59:50 | state: fix unbound virtual modifier bug Recent xkeyboard-config introduced the following line in symbols/level3: vmods = LevelThree, However, the XKM format which xkbcomp produces for the X server can't handle explicit virtual modifiers such as this: https://bugs.freedesktop.org/show_bug.cgi?id=4927 So by doing the following, for example: setxkbmap -layout de (or another 3-level layouts) xkbcomp $DISPLAY out.xkb xkbcomp out.xkb $DISPLAY The modifier is lost and can't be used for switching to Level3 (see the included test). We, however, are affected worse by this bug when we load the out.xkb keymap. First, the FOUR_LEVEL_ALPHABETIC key type has these entries: map[None] = Level1; map[Shift] = Level2; map[Lock] = Level2; map[LevelThree] = Level3; [...] Now, because the LevelThree virtual modifier is not bound to anything, the effective mask of the "map[LevelThree]" entry is just 0. So when the modifier state is empty (initial state), this entry is chosen, and we get Level3, instead of failing to match any entry and getting the default Level1. The difference in behavior from the xserver stems from this commit: acdad6058d52dc8a3e724dc95448300850d474f2 Which removed the entry->active field. Without bugs, this would be correct; however, it seems in this case we should just follow the server's behavior. The server sets the entry->active field like so in XKBMisc.c: /* entry is active if vmods are bound */ entry->active = (mask != 0); The xkblib spec explains this field, but does not specify how to initialize it. This commit does the same as above but more directly. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
bc7b2ff2 | 2013-02-17 13:39:41 | test/keyseq: re-add de(neo) level5 test See: https://bugs.freedesktop.org/show_bug.cgi?id=50935 This works now after syncing with recent xkeyboard-config. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
94155878 | 2012-10-29 20:20:51 | test/keyseq: add test for setting depressed group Tests the SetGroup action is working properly. Signed-off-by: Ran Benita <ran234@gmail.com> | |
 |
7b3bd11f | 2012-10-16 16:05:34 | Add xkb_keysym_from_name() flags argument for case-insensitive search This adds a flags argument to xkb_keysym_from_name() so we can perform a case-insensitive search. This should really be supported as many keysyms have really weird capitalization-rules. However, as this may produce conflicts, users must be warned to only use this for fallback paths or error-recovery. This is also the reason why the internal XKB parsers still use the case-sensitive search. This also adds some test-cases so the expected results are really produced. The binary-size does _not_ change with this patch. However, case-sensitive search may be slightly slower with this patch. But this is barely measurable. [ran: use bool instead of int for icase, add a recommendation to the doc, and test a couple "thorny" cases.] Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> | |
|
fcd20290 | 2012-09-21 14:44:17 | Don't use xkbcommon-compat names in internal code Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
67b03cea | 2012-09-21 16:30:01 | state: correctly wrap state->locked_group and ->group These values weren't wrapped before, which caused group_index_is_active to stop working after a few group switches. Also, the current group-wrapping function didn't take into consideration actions such as LockGroup=-1, which need to wrap around, etc. xkb_layout_index_t is unsigned, but it was used to hold possibly negative values (e.g. locked_group is 0 and gets a -1 action). This group wrapping function should now act like the XkbAdjustGroup function from xserver, and at least ./test/interactive doesn't bring up any problems with group switching any more. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
dbd7a953 | 2012-09-16 15:57:36 | keyseq: add test for repeat-shift-repeat-unshift-repeat e.g. hhhhhHHHHHHHhhhhhh with shift down and up in the middle. Unfortunately trying a quick test with test/interactive is not possible because the evdev soft-repeat stops the repeat when another key is pressed. So you need real soft-repeat for that. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b2110705 | 2012-09-16 14:45:32 | Organize src/ and test/ headers - Add context.h and move context-related functions from xkb-priv.h to it. - Move xkb_context definition back to context.c. - Add keysym.h and move keysym upper/lower/keypad from xkb-priv.h to it. - Rename xkb-priv.h to map.h since it only contains keymap-related definitions and declarations now. - Remove unnecessary includes and some and some other small cleanups. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
8862fd80 | 2012-09-13 11:49:02 | keyseq: test that de(neo) is working properly This layout stretches us pretty well, so it's good for testing nothing breaks. There are a couple of things that need looking into, though (particularly the level5 issue). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3abfe83e | 2012-09-12 23:51:19 | symbols: fix real/alias key merge ordering bug Background: The CopySymbolsDef has a comment on a couple of lines which supposedly fixed a bug: /* * kt_index[i] may have been set by a previous run (if we have two * layouts specified). Let's not overwrite it with the ONE_LEVEL * default group if we dont even have keys for this group anyway. * * FIXME: There should be a better fix for this. */ if (!darray_empty(groupi->levels)) key->kt_index[i] = types[i]; But neither the comment nor the fix make any sense, because the kt_index is indexed per group, i.e. each group gets its own type. The original xkbcomp commit which added this (36fecff58) points to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=436626 which complains about -layout "ru,us" -variant "phonetic," not working properly. And indeed when we try: sudo ./test/interactive -l ru,us -v the first group doesn't get any syms for the main keys. The problem (Clearly the fix above is useless): The ru(phonetic) map is specified using aliases, e.g. LatQ, LatW instead of AD01, AD02, etc. When combined with another layout which uses the real names (AD01, AD02), the symbols code should recognize they are the same key and merge them into one KeyInfo. The current code does that, but it doesn't catch the case where the alias was processes *before* the real one; so we get two KeyInfo's and the later one wins. So e.g. the ru(phonetic) symbols are ignored. The fix: Before adding a new KeyInfo to the keys array, always replace its name by the real name, which avoids the entire issue. Luckily this is done pretty late so most error messages should still show the alias name. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
cfd978b8 | 2012-08-02 00:40:22 | keyseq: use our own keysyms Instead of <X11/keysym.h> Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
81d029f5 | 2012-07-15 11:52:54 | Replace xkb_keycode_t 'key' variable name by 'kc' We want to reserve the name 'key' for something else. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3e86ebca | 2012-07-12 14:15:08 | Add a library of common test functions Including creating a context (will come in useful soon), opening and reading files, and compiling keymaps. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
1f492901 | 2012-07-11 18:00:31 | Enlarge keysym name buffers and mention in comment The longest keysym is 27 chars long. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
09d1445b | 2012-07-11 14:12:12 | keyseq: add a failing group-switching test For some reason, with the grp:alt_shift_toggle option, the following sequence switches a group: < Left Shift down, Left Alt down > While the reverse doesn't: < Left Alt down, Left Shift down > And it should. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
e201c165 | 2012-06-30 00:07:09 | state: fix base mod set/clear behavior This commit fixes the incorrect current behavior, where at the end of the following key sequence Left Shift down, Right Shift down, Left Shift up the Shift modifier is cleared. Clearly the code is not as nice as before, but it seems like some count of the depressed modifiers must be kept. The code is lifted mostly as is from xkbActions.c. [ There they also assign to setMods and clearMods each time and not OR it. I assume its correct, although I wouldn't have guessed... ] Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
0015604a | 2012-04-10 21:20:27 | Add a test for the results of key sequences This test verifies the core purpose of this library, which is to translate the user's keypresses into keysyms according to the keymap and the XKB specification. The tests emulate a series of key presses, and checks that the resulting keysyms are what we expect. Several of the tests currently fail, and plenty more should be added and maybe split up. It also currently uses an RMLVO keymap, which comes from the xkeyboard-config data set, and whose behaviour may change in the future. So it should probably be changed to use several files of our own, but it's OK for now. Signed-off-by: Ran Benita <ran234@gmail.com> |