kc3-lang/libxkbcommon/test/state.c
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
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. | |
|
ee87f6ed | 2025-06-21 19:28:53 | state: Fix broken latch not honoring clearLocks=no Before this commit, breaking a latch (modifier & group) would always clear locks, even if `clearLocks=no`. | |
|
94d8e341 | 2025-06-21 13:17:16 | state: Fix LatchMods mutation to SetMods or LockMods Previously we use inlined version of the corresponding filter functions of the `SetMods()` and `LockMods()` actions, but they were incomplete and did not set some fields (`priv`, `refcnt`) properly. Also, it is error-prone: it requires discipline to keep it in sync. E.g. before this commit, converting to `LockMods()` would always try to unlock `CapsLock` due to the wrong value of the `priv` field. Fixed by using the corresponding filter functions directly, so that we always mutate the filter properly, as in `xkb_filter_group_latch_func`. | |
|
ac9cd053 | 2025-06-11 19:00:47 | test: Check extended layout indexes | |
|
717ce258 | 2025-06-11 18:34:15 | test: Refactor rules-file and state Split into dedicated functions fo better readability. | |
|
2acf5eca | 2025-06-09 16:26:56 | test: Use explicit keymap format in test_compile_buffer() | |
|
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. | |
|
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. | |
|
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> | |
|
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. | |
|
230b6a6a | 2025-05-06 14: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 | |
|
9ede705b | 2025-04-13 09:50:18 | state: Capitalization transformation in xkb_state_key_get_syms Previously `xkb_state_key_get_syms()` did not perform capitalization tranformation, while `xkb_state_key_get_one_sym()` does perform it. This is unfortunate if we want to promote the use of multiple keysyms per levels. The API make it difficult to change now though: we return a pointer to an immutable array rather than filling a buffer. While we could use an internal buffer in `xkb_state`, this option would limit the API to *sequential* calls of `xkb_state_key_get_syms()` or require some buffer handling (e.g. rotation). Instead we now store the capitalization directly in `xkb_level`. We modified `xkb_level` like so (see below for discussion about the size): ```diff struct xkb_level { - unsigned int num_syms; + uint16_t num_syms; - unsigned int num_actions; + uint16_t num_actions; + union { + /** num_syms == 1: Upper keysym */ + xkb_keysym_t upper; + /** num_syms > 1: Indicate if `syms` contains the upper case + * keysyms after the lower ones. */ + bool has_upper; + }; union { xkb_keysym_t sym; /* num_syms == 1 */ xkb_keysym_t *syms; /* num_syms > 1 */ } s; union { union xkb_action action; /* num_actions == 1 */ union xkb_action *actions; /* num_actions > 1 */ } a; }; ``` - When `level.num_syms` <= 1, we store the upper keysym in `level.upper`. - Else if there no cased syms, we set `level.has_upper` to false. - Else if there are some cased syms, we set `level.has_upper`` to `true` and we double the original size of `level.s.syms`, but *without* modifying `level.num_syms`. We then append the transformed keysyms right after the original ones, so that we can access them by a simple pointer operation: `level.s.syms + level.num_syms`. The memory footprint is *unchanged*, thanks to the reduced fields for actions and keysyms counts. | |
|
36442baa | 2025-04-03 15:01:46 | xkbcomp: Support multiple actions in interpret Before this commit we supported multiple actions per level, but not in *interpret* statements. Let’s fix this asymmetry, so we can equivalently assign all actions sets either implicitly or explicitly. | |
|
b254cc2e | 2025-03-30 12:27:15 | test: Remove empty components boilerplate | |
 |
cb3565b1 | 2025-03-07 17:59:33 | keymap: Fix segfault due to invalid group wrapping The modular arithmetic is incorrect for negative values, e.g. for num_groups = 1. It triggers a segfault for the following settings: - layouts count (per key or total) N: `N > 0`, and - layout index n: `n = - k * N` (`k > 0`) % returns the *remainder* of the division, not the modulus (see C11 standard 6.5.5 “Multiplicative operators”: a % b = a - (a/b)*b. While both operators return the same result for positive operands, they do not for e.g. a negative dividend: remainder may be negative (in the open interval ]-num_groups, num_groups[) while the modulus is always positive. So if the remainder is negative, we must add `num_groups` to get the modulus. Fixes: 67b03cea ("state: correctly wrap state->locked_group and ->group") Signed-off-by: Julian Orth <ju.orth@gmail.com> Co-authored-by: Julian Orth <ju.orth@gmail.com> Co-authored-by: Pierre Le Marre <dev@wismill.eu> | |
 |
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> | |
|
c85c9bdc | 2025-01-27 17:15:06 | symbols: Allow levels with different keysyms and actions counts Contrary to groups, there is no reason for levels to restrict the same count of keysyms and actions. | |
|
0c940827 | 2025-01-22 16:39:35 | clang-tidy: Macro arguments should be enclosed in parentheses | |
|
c7fdf506 | 2025-01-16 20:23:28 | Use portable integer literal suffixes | |
|
325ba10e | 2025-01-07 16:27:50 | state: Fix LEDs driven by the group state When the indicator field `whichGroupState` is set to `Base` or `Latched`, the group masks should be considered only as boolean values as per the XKB specification. | |
|
7d08bf43 | 2025-01-07 18:33:21 | state: Add test for LEDs driven by the group state | |
|
e0130e30 | 2024-11-18 20:08:56 | state: Add vmod support for xkb_state_mod_mask_remove_consumed | |
|
5fbc0ec7 | 2024-10-14 16:05:52 | state: Support querying whether virtual mods are consumed Previously it was not possible to query the status of virtual modifiers with the following functions: - `xkb_state_mod_index_is_consumed` - `xkb_state_mod_index_is_consumed2` Note that it may *overmatch* if some modifier mappings overlap. For example, the default “us” PC layout maps both “Alt” and “Meta” to the real modifier “Mod1”; thus “Mod1”, “Alt” and “Meta” modifiers will return the same result with these functions. | |
|
31a841ae | 2024-10-14 16:05:35 | state: support querying whether virtual modifiers are active Previously it was not possible to query the status of virtual modifiers with the following functions: - `xkb_state_mod_index_is_active` - `xkb_state_mod_indices_are_active` - `xkb_state_mod_name_is_active` - `xkb_state_mod_names_are_active` Note that it may *overmatch* if some modifier mappings overlap. For example, the default “us” PC layout maps both “Alt” and “Meta” to the real modifier “Mod1”; thus “Mod1”, “Alt” and “Meta” modifiers will return the same result with these functions. | |
|
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`. | |
|
0d01a933 | 2023-07-04 09:34:08 | Replace keycode numeric offset with EVDEV_OFFSET Add a constant `EVDEV_OFFSET` to make the semantic of the offset clearer. | |
|
1c352199 | 2020-09-07 11:35:22 | test/data: sync from xkeyboard-config 2.30 Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
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> | |
 |
babc9e0c | 2016-02-27 22:31:16 | state: add GTK consumed modifiers mode This is more or less what is implemented here: https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkkeys-x11.c?h=3.19.10#n1131 The implementation here is more technically correct but should provide the same results. Try it out with ./test/interactive-evdev -g (modifiers prefixed with "-" are consumed). https://bugzilla.gnome.org/show_bug.cgi?id=754110 https://github.com/xkbcommon/libxkbcommon/issues/17 Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
914c060a | 2016-10-22 20:13:11 | test/state: move wrongly-placed assert 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> | |
|
f3597f1b | 2014-08-18 21:03:06 | test/state: add test_update_mask() test Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
54174409 | 2014-03-27 17:42:20 | state: fix consumed modifier calculation The current calculation is in short: entry ? (entry->mask & ~entry->preserve) : 0 This changes it be type->mask & ~(entry ? entry->preserve : 0) This is what Xlib does. While less intuitive, it is actually more correct, if you follow this deduction: - The key group's type->mask defines which modifiers the key even cares about. The others are completely irrelevant (and in fact they are masked out from all sided in the level calculation). Example: NumLock for an alphabetic key. - The type->mask, the mods which are not masked out, are *all* relevant (and in fact in the level calculation they must match *exactly* to the state). These mods affect which level is chosen for the key, whether they are active or not. - Because the type->mask mods are all relevant, they must be considered as consumed by the calculation *even if they are not active*. Therefore we use type->mask instead of entry->mask. The second change is what happens when no entry is found: return 0 or just take preserve to be 0? Let's consider an example, the basic type type "ALPHABETIC" { modifiers = Shift+Lock; map[Shift] = Level2; map[Lock] = Level2; level_name[Level1] = "Base"; level_name[Level2] = "Caps"; }; Suppose Shift+Lock is active - it doesn't match any entry, thus it gets to level 0. The first interpretation would take them both to be unconsumed, the second (new one) would take them both to be consumed. This seems much better: Caps is active, and Shift disables it, they both do something. This change also fixes a pretty lousy bug (since 0.3.2), where Shift appears to apparently *not* disable Caps. What actually happens is that Caps is not consumed (see above) but active, thus the implicit capitalization in get_one_sym() kicks in and capitalizes it anyway. Reported-by: Davinder Pal Singh Bhamra Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3cfa7fda | 2014-03-21 23:00:37 | state: apply control transformation on utf8/utf32 keysym strings This is required by the specification: http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Control_Modifier and clients expect this to happen. https://bugs.freedesktop.org/show_bug.cgi?id=75892 Reported-by: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b973d71e | 2014-03-21 23:00:17 | state: add xkb_state_key_get_{utf8,utf32}() API functions These functions generally have the same effect as xkb_state_key_get_syms() + xkb_keysym_to_utf{8,32}(). So why add them? - They provide a slightly nicer interface, especially if the string is the only interest. - It makes the handling of multiple-keysyms-to-utf8 transparent. For the designated use-case of multiple-keysyms (unicode combining characters), this is a must. We also validate the UTF-8, which the user might not otherwise do. - We will need to apply some transformation on the resulting string which depend on the xkb_state. This is not possible with the xkb_keysym_* functions. With these functions, the existing xkb_keysym_to_utf{8,32}() are not expected to be used by a typical user; they are "raw" functions. Signed-off-by: Ran Benita <ran234@gmail.com> | |
 |
4fb7b06b | 2014-02-21 18:09:00 | state: Add xkb_state_key_get_consumed_mods This retrieves the mask of consumed modifiers for a given key and state, which is helpful for toolkits without having them to do it one modifier at a time, or pass in 0xFFFFFFFF to xkb_state_remove_consumed_mods to "reverse-engineer" the consumed mods. | |
|
94e0be0d | 2014-02-08 00:42:54 | test/state: fix tautological test test/state.c:376:5: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
623b10f8 | 2014-02-08 00:27:54 | Fix sign-compare warnings Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4841ea0c | 2014-01-11 16:56:20 | test/state: fix some *_{is,are}_active() tests These functions also return -1 on invalid input. The original tests didn't check that, but used !tests instead. Since then we've changed them, but some were missed, and for some we forgot to remove the ! (or you can say they were extra clever). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
59fb79e7 | 2013-09-25 10:05:26 | test/state: fix missing xkb_state_unref Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
2a2a8d7d | 2013-08-13 18:57:43 | state: apply capitalization transformation on keysyms The xkbproto spec says: http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Lock_Modifier If the Lock modifier is not consumed by the symbol lookup process, routines that determine the symbol and string that correspond to an event should capitalize the result. This was not an issue until now, because most xkeyboard-config keymaps do not utilize this "feature", and specify the keysyms for the Lock modifier explicitly instead. However, some keymaps do depend on it, e.g. ch(fr) for eacute and others. The spec goes on to describe two options for doing this transformation: locale-sensitive and locale-insensitive. We opt for the latter; it is less desirable but we don't want *that* headache. Also, only xkb_state_key_get_one_sym() is changed; xkb_state_key_get_syms() is left as-is, and always reports the untransformed keysyms. This is for the following reasons: - The API doesn't allow it, since we return a const pointer directly to the keymap keysyms table and we can't transform that. - The transformation doesn't make sense for multiple-keysyms. - It can be useful for an application to get the "raw" keysyms if it wants to (e.g. maybe it wants to do the transformation itself). Finally, note that xkb_state_mod_index_is_consumed() does *not* report Lock as consumed even if it was used in the transformation. This is what Xlib does. This definitely doesn't fall under the "hard to misuse" API rule but it's the best we can do. https://bugs.freedesktop.org/show_bug.cgi?id=67167 Reported-By: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com> | |
 |
b06de307 | 2013-05-09 15:31:21 | Add keycode min/max and iteration API Add three new pieces of API: - xkb_keymap_min_keycode does what it says on the tin - xkb_keymap_max_keycode likewise - xkb_keymap_key_for_each calls the provided function once for every valid key in the keymap Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
 |
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> | |
|
7261f404 | 2012-10-29 01:00:27 | state, context: allow passing NULL to *_unref() For error handling code, it's nice to be able to pass NULL to these function without worrying about segfaults ensuing. free() sets the precedent here. Also document this fact. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
6a94b122 | 2012-10-22 20:49:44 | Split the mods, layout, leds parts of xkb_state_components Note first: This commits breaks the ABI somewhat. If an application is run against this commit without recompiling against the updated header, these break: - xkb_state_layout_*_is_active always retuns false. - xkb_state_serialize_mods always returns 0. So it might break layout switching in some applications. However, xkbcommon-compat.h provides the necessary fixes, so recompiling should work (though updating the application is even better). Split the enum to its individual components, which enables us to refer to them individually. We will use that later for reporting which components of the state have changed after update. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
bbf388ec | 2012-10-11 16:54:17 | Make xkb_keymap_num_leds return the index range instead of active count Currently xkb_keymap_num_leds() returns a count of valid (settable) leds. Because the indexes might be non-consecutive, and some leds might not be settable, it is incorrect to use this function for iterating over the leds in the keymap. But this is the main use case of this function, so instead of the current behavior we adapt the function to the use case by making it return the needed range of iteration. The caller needs to handle invalid intermittent indexes, though. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
2f4db8a9 | 2012-10-10 09:47:31 | keymap, state: don't assume led index < xkb_keymap_num_leds xkb_keymap_num_leds() returns the number of leds that have any possibility of being set. Even if a led is defined but can not be set in any way, it is not counted. In a few places currently we assume that led indexes are smaller than this number, which is wrong both for the above reason and for the fact that the xkb format actually allows explicitly setting the indicator index, which means that the indexes might be non-consecutive. We don't really have good API to iterate on leds, now, because xkb_keymap_num_leds is pretty useless. To work around that we use sizeof(xkb_led_mask_t) * 8. This makes the "Group 2" led work (try switching to a layout other than the first in test/interactive). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
1a6b1e07 | 2012-10-03 19:41:22 | state: fix bad EFFECTIVE check in *_is_active() This is a regression introduced in ed78fbcb30888cbfc6cd00. XKB_STATE_EFFECTIVE is just a OR of the other states, so using & here is completely wrong. So test/state shows for example: dumping state for LCtrl down: group English (US) (0): effective depressed latched locked mod Control (2): depressed latched locked dumping state for LCtrl + RAlt down: group English (US) (0): effective depressed latched locked mod Control (2): depressed latched locked mod Mod1 (3): depressed latched locked dumping state for RAlt down: group English (US) (0): effective depressed latched locked mod Mod1 (3): depressed latched locked dumping state for Caps Lock: group English (US) (0): effective depressed latched locked mod Lock (1): depressed latched locked led Caps Lock (0): active dumping state for Alt-Shift-+ group English (US) (0): effective depressed latched locked mod Shift (0): depressed latched locked mod Mod1 (3): depressed latched locked which is bogus. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
5aaf65b7 | 2012-09-27 23:27:49 | Add xkb_state_key_get_one_sym The trivial wrapper around xkb_state_key_get_syms that every user to date has implemented. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
fcd20290 | 2012-09-21 14:44:17 | Don't use xkbcommon-compat names in internal code Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
06d7803a | 2012-08-30 12:13:37 | state: fix mod_names_are_active This function was always returning -1. Adding a test, we see that test/state.c treat the is_active functions as returning booleans, which would treat -1 as success, so we test for > 0 instead (most users would probably get this wrong as well...). Also update the documentation for the are_active functions, and add a ATTR_NULL_SENTINEL for gcc __attribute__((sentinel)). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
2f1f1bca | 2012-08-08 14:26:23 | Add xkb_map_mod_mask_remove_consumed A fairly simple helper which, given an xkb_mod_mask_t, removes all modifiers which are consumed during processing of a particular key. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
6021a976 | 2012-08-03 03:45:14 | test: Minimise includes Mostly from functions which used to use file functions directly, but now use test.h wrappers. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
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> | |
|
6d606d10 | 2012-06-22 15:29:47 | state: Add more comprehensive repeating test Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
8e2c66e9 | 2012-06-22 15:27:05 | Add xkb_key_repeats Does what it says on the box. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
955ed8c4 | 2012-06-06 10:38:45 | state: use darray for filters For the darray we need to specify the explicit struct xkb_filter type instead of void*, so we move the definition of struct xkb_state into state.c thus making it opaque even from the rest of the files. It has enough getters to get going and is otherwise good style. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
7b00485a | 2012-05-11 15:03:43 | Rename 'ctx' back to 'context' in external API Still keep things as 'ctx' internally so we don't have to worry about typing it too often, but rename the user-visible API back as it was kinda ugly. This partially reverts e7bb1e5f. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
2761b1a3 | 2012-05-09 20:20:12 | Rename serialise to serialize Yes, British English is correct, but unfortunately we've lost that battle. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
5a3771d1 | 2012-05-09 20:18:30 | Add common LED names to xkbcommon-names.h Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
6433d72e | 2012-05-09 20:12:12 | Merge remote-tracking branch 'krh/keysyms' Conflicts: src/keysym.c src/misc.c src/text.h src/xkbcomp/expr.c src/xkbcomp/parser.y src/xkbcomp/parseutils.c src/xkbcomp/symbols.c Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
 |
ace1e5df | 2012-05-09 09:05:00 | Use our own keysyms | |
|
e7bb1e5f | 2012-05-09 15:03:11 | Shorten context to ctx (This breaks the API.) "context" is really annoying to type all the time (and we're going to type it a lot more :). "ctx" is clear, concise and common in many other libraries. Use it! Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Fix for xkb -> keymap change.] | |
|
38cb6390 | 2012-05-09 15:15:30 | Change all 'xkb' xkb_keymap names to 'keymap' To make it a bit more clear what it actually is. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
124e62e4 | 2012-05-09 01:06:10 | Add multiple modifier state matching API Two new calls allow users to test the exact modifier state, including verifying that no other modifiers but the ones you wanted are down. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
74a197d2 | 2012-05-08 17:59:35 | Add pre-defined names database xkbcommon-names.h right now just contains a set of hardcoded modifier strings that are most commonly used for the usual modifiers. Provide definitions of these so people don't have to worry about typoing a string or mixing up Mod1 and Mod4. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
c3584280 | 2012-05-08 17:51:16 | Add flags to context creation None defined as yet, but why not. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
b537b552 | 2012-05-08 17:48:29 | Add flags to keymap compilation entrypoints No use as yet, but might as well ... Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
b610b2b9 | 2012-05-08 14:52:23 | Rename XKBcommonint.h to xkb-priv.h and use it Make the files in the src/* directory use their own header or a consilidated private header. This makes the file dependencies clearer. Also drop the pointless "xkb" file name prefix, add split a few declarations to their own files (atom.h and text.h). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4b49e0a1 | 2012-03-31 02:44:39 | Overhaul test suite Rewrite all of the current tests in the following ways: - Instead of the current mix of C and shell, just use single-process pure C file per test. All of the .sh files are removed, but everything that was tested is ported. - Instead of handling the test logs ourselves, use Automake's "parallel-test" mechanism. This will create a single log file for each test with it's stdout+stderr, and a top level "test-suite.log" file for all the failed tests. - The "parallel-tests" directive also makes the test run in parallel, so "make check" runs faster. - Also use the "color-tests" directive to have the "make check" output colorized. Who doesn't like to see PASS in green? - All of the test data files are moved into the test/data subdirectory. That way we can just put the directory in EXTRA_DIST and forget about it. - The test/Makefile.am file is consolidated into the main Makefile.am, for a completely non-recursive build. Right now the tests are completely independent and just use simple assert()'s. More sophistication can be added as needed. It should also be noted that it's still possible to use shell, python, etc. if a test wants more flexibility than C can provide, just do as before. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated for xkb_keymap changes.] | |
|
ef88c7ef | 2012-04-03 15:14:16 | Rename xkb_desc to xkb_keymap struct xkb_desc was just a hangover from the old XkbDescRec, which isn't a very descriptive name. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
034ffce6 | 2012-03-27 17:22:35 | Use xkb_contexts in keymap compilation Primarily for the include path, but also for the logging in future. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
d3908b63 | 2012-03-24 12:33:28 | Define our own None atom value Since we define our own xkb_atom_t type, it makes sense not to use the X11/X.h None value. This way we can also remove a lot of X11 includes. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
d22b8dbb | 2012-03-23 22:25:47 | Move utils.{c,h} to be used by the entire project This is a first step for making consistent use of utils.h also outside of xkbcomp/ . Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
ede84734 | 2012-03-27 12:11:45 | Add enum xkb_key_direction instead of bool Use XKB_KEY_UP instead of 0 and XKB_KEY_DOWN instead of 1. Signed-off-by: Daniel Stone <daniel@fooishbar.org> Reported-by: Ran Benita <ran234@gmail.com> | |
|
7f471a70 | 2012-03-27 12:07:57 | Add state serialisation API Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
d039622a | 2012-03-22 17:39:12 | Rename keymap allocation API Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
3d672fcf | 2012-03-22 14:32:53 | Add LED state API And also convert state.c to use the state API for mods and groups, rather than testing the state members directly. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
edcaab65 | 2012-03-21 15:25:32 | Round out new state API Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
ecea0d71 | 2012-03-21 02:20:07 | Add new state API Add new API to deal with xkb_state objects, including xkb_state_update_key, which runs the XKB action machinery internally to calculate what exactly happens to the state when a given key is pressed or released. The canonical way to deal with keys is now: struct xkb_state *state = xkb_state_new(xkb); xkb_keysym_t *syms; int num_syms; xkb_state_update_key(state, key, is_down); num_syms = xkb_key_get_syms(state, key, &syms); More state handling API, including a way to get at or ignore preserved modifiers, is on its way. Signed-off-by: Daniel Stone <daniel@fooishbar.org> |