kc3-lang/libxkbcommon/src/state.c
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
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> | |
|
be38862b | 2013-07-26 00:50:26 | keymap: remove struct xkb_key_redirect_action The file src/xkbcomp/action.c already doesn't handle this action type and fails if it encounters it. So lets not pretend to do something with it, and ignore it rather than failing. If we/someone wants this we can consider implementing it. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
57bfde3a | 2013-03-04 18:41:13 | keymap: rename xkb_kt_map_entry to xkb_key_type_entry That's a better name and fits more nicely. Also change type->map to type->entries. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9f75e0ab | 2013-03-07 01:15:21 | state: use stdbool in filters Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
cd6a71fc | 2013-03-04 02:12:00 | state: small style fix Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
8cee7490 | 2013-02-17 22:18:57 | Change 'indicator' to 'led' everywhere possible The code currently uses the two names interchangeably. Settle on 'led', because it is shorter, more recognizable, and what we use in our API (though of course the parser still uses 'indicator'). In camel case we make it 'Led'. We change 'xkb_indicator_map' to just 'xkb_led' and the variables of this type are 'led'. This mimics 'xkb_key' and 'key'. IndicatorNameInfo and LEDInfo are changed to 'LedNameInfo' and 'LedInfo', and the variables are 'ledi' (like 'keyi' etc.). This is instead of 'ii' and 'im'. This might make a few places a bit confusing, but less than before I think. It's also shorter. 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> | |
|
f1598469 | 2012-11-11 16:14:30 | state: rename state->cur to state->components 'cur' doesn't make sense anymore. 'components' is a bit long for this, but not too bad, and nothing better comes to mind. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
7372c9f1 | 2012-11-11 16:06:54 | state: don't keep the previous state components in xkb_state There is really no need to keep this in the struct, we can just allocate it on the stack when we need to. Don't know why I did it this way. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
60bd9202 | 2012-11-11 00:22:46 | keymap: wrap the layout parameter if it is out of range for the key The functions num_levels_for_key() and get_syms_by_level() have a 'layout' parameter. Currently it is expected that this value is always legal for the key, as determined by num_layouts_for_key(). However, there are legitimate use cases for passing an out-of-range layout there, most probably passing the effective layout, and expecting to get the keysyms/levels for just this layout. So we wrap it just as we do in the xkb_state_* functions. This is also useful for stuff like this: http://developer.gnome.org/gdk/stable/gdk-Keyboard-Handling.html#gdk-keymap-lookup-key If this behavior is not desired, the user has the option to check against num_layouts_for_key herself. https://bugs.freedesktop.org/show_bug.cgi?id=56866 Reported-by: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
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> | |
|
a51ee704 | 2012-10-26 16:24:11 | state: don't use xkb_keymap_num_layouts internally Clearer and more greppable this way. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
ee6f3f28 | 2012-10-26 16:12:28 | state: don't use xkb_state_serialize_* internally The code in these cases is clearer when done directly. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
6f093ad5 | 2012-10-24 23:09:26 | state: fix possible index-out-of-bounds in action dispatch table The current code assumes that action->type always falls in the range of the xkb_action_type enum. But keymaps can also have Private actions, which are allowed to set their own type number. So with a default xkeyboard-config keymap, keycode 86 at level 4, which triggers such an action, causes us to crash. Fix it by always checking the bounds. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
867992cd | 2012-10-23 17:17:18 | state: fix typo in state component copying Gladly no-one should have been fast enough to hit this. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4b81c9f3 | 2012-10-22 21:00:57 | Report which components of the state have changed We add a return value to the xkb_state_update_key and xkb_state_update_mask, which reports to the caller which of the state components have changed as a result. This restores the XKB functionality of the XkbStateNotify and XkbIndicatorsStateNotify events. See: http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Events It is quite useful in some situations. For example, it allows an application to avoid doing some work if nothing of relevance in the state has changed. Say, a keyboard layout applet. Also useful for debugging. The deltas themselves are not provided, because I can't see a use case. If needed, it should be possible to add some API for that. In xkbcommon, keymaps are immutable, so all of the other *Notify events from XKB are irrelevant. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
550cb24d | 2012-10-22 19:19:43 | state: add struct state_components This holds all of the state component fields in the state in one struct. We will later want to keep the previous state components after updates, so this will allow us to do it without duplicating the fields. 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> | |
|
f43b33c0 | 2012-10-13 13:13:55 | state: make mod_index_is_consumed() return -1 on invalid input Like all the other functions. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9197eb0f | 2012-10-10 19:08:01 | Remove the XKB_NUM_INDICATORS limit Use a darray instead of a static array of size 32. We still enforce XKB_MAX_LEDS because of the size of xkb_led_mask_t. 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> | |
|
b65980cc | 2012-10-05 15:10:41 | state: don't needlessly fetch the xkb_key It's a leftover. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
8016c6f4 | 2012-10-03 20:21:05 | state: simplify xkb_state_mod_index_is_active Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
e5b6055b | 2012-10-03 20:16:09 | state: don't ignore type argument in xkb_state_mod_*_are_active 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> | |
|
fe1faa14 | 2012-10-03 20:08:13 | Use our types instead of int/uint32_t in a few places Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
11df0632 | 2012-09-27 21:11:11 | state: add missing const in get_one_sym 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> | |
|
5d265926 | 2012-09-24 14:57:30 | keymap: remove some more unneeded macros It clearer to just access the needed data directly. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
c955f8e2 | 2012-09-24 14:41:09 | keymap: store a pointer to the type in xkb_group instead of index Gets rid of some more unneeded indirection, including the XkbKeyType macro. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
01b00d75 | 2012-09-24 12:11:31 | keymap, symbols: improve xkb_key memory layout Add struct xkb_group and xkb_level for use in xkb_key, to mirror how it's done in KeyInfo, GroupInfo, LevelInfo in symbols.c. This corresponds more nicely to the logical data layout (i.e. a key has groups which have levels), and also removes a lot of copying and ugly code due to the index indirections and separate arrays which were used before. This uses more memory in some places (e.g. we alloc an action for every level even if the key doesn't have any) but less in other places (e.g. we no longer have to pad each group to ->width levels). The numbers say we use less overall. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
419a4975 | 2012-09-21 21:16:20 | state: missing XKB_EXPORT on xkb_state_key_get_level And some error handling. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
ed78fbcb | 2012-09-21 12:45:58 | state: special case effective group in layout_is_active Currently, xkb_state_layout_{index,name}_is_active may report multiple groups as effective, because at looks at base,latched,locked separately. But there can only be one effective group, which is computed from the other three. So if XKB_STATE_EFFECTIVE is requested, just compare to the effective group we have computed. We also modify mod_{index,name}_is_active similarly, just for symmetry (there the effective mask is just an OR of the other three so the current test is correct). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
bbaa11c6 | 2012-09-21 14:58:31 | Rename map.{c,h} to keymap.{c,h} Seeing as we don't like "map" anymore. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
7dca986e | 2012-09-21 14:55:46 | state, map: check XkbKey != NULL where missing Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
debd62b5 | 2012-09-21 13:30:42 | Move xkb_state functions from map.c to state.c Seems more appropriate. Only change is to turn some xkb_state_get_map functions to direct state->keymap. Signed-off-by: Ran Benita <ran234@gmail.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> | |
|
bf194080 | 2012-09-19 16:19:57 | Promote keymap enumeration API to public Rename the functions to get keysyms by key/layout/level to fit with the recent public API renames, and expose them. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
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> | |
|
7d1db12d | 2012-09-21 15:39:32 | state: separate group wrapping/clamping to a function We'll need this function for wrapping our global effective group as well. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
6b66afc4 | 2012-09-19 15:56:07 | state: handle ACTION_LOCK_NO_{UN,}LOCK for mods xkblib spec says: XkbSA_LockNoLock If set, and the action type is XkbSA_LockMods, the server only unlocks the action modifiers. XkbSA_LockNoUnlock If set, and the action is XkbSA_LockMods, the server only locks the action modifiers. 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> | |
|
9a27ac72 | 2012-09-14 16:10:47 | state: use filter->priv instead of modifying the action in xkb_filter_group_set_new. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
8098daa0 | 2012-09-14 16:01:11 | state: move filter initialization to the dispatcher This removes all of the boilerplate from the *_new functions, and leaves them just as simple functions which perform the effect of the action on state. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
2c19c938 | 2012-09-14 15:33:54 | state: call xkb_filter_new from the dispatcher Pass the new filter as a parameter instead of getting a new one in each action function, and introducing a failure condition there. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
04f1b3be | 2012-09-14 15:29:12 | state: dispatch actions from a table Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
16425ffa | 2012-09-14 11:26:36 | state: don't keep the xkb_state in the filters Just pass it as a parameter: to make state.c a bit less stateful. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
c2570d51 | 2012-09-14 11:17:30 | state, map: constify references to xkb_key Makes it clear that we treat the keys as immutible values in these files. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
841f3223 | 2012-09-14 11:02:12 | state, map: use keycodes only for the API functions The policy is now consistent: every API functions which recieves a keycode should resolve it to an xkb_key first thing, and all the internal functions use that instead of the keycode. To facilitate it a bit, we move the KeycodeInRange check to XkbKey itself, which returns NULL if the keycode is illegal. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
886b0ca5 | 2012-09-10 23:24:19 | state: remove unused next field from xkb_filter Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b4b40d73 | 2012-09-12 16:54:07 | Copyright updates With Dan Nicholson's permission (via email), update his copyright and license statements to the standard X.Org boilerplate MIT license, as both myself and Ran have been using. Clean up my copyright declarations (in some cases to correct ownership), and add copyright/license statements from myself and/or Ran where appropriate. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
70c775f6 | 2012-09-10 20:38:46 | kbproto unentanglement: action flags Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
830fe671 | 2012-09-10 20:07:54 | kbproto unentanglement: XkbIM_* Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
0b2506db | 2012-09-10 19:23:16 | kbproto unentanglement: action types Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
74ec4c1c | 2012-08-21 12:47:28 | kbproto unentanglement: XkbNumIndicators Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
82491d5f | 2012-08-30 12:14:29 | map, state: check for KeycodeInRange only in API functions 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> | |
|
9f0c0160 | 2012-08-30 11:21:03 | state: fix type confusion within xkb_state_update_mask idx should be xkb_mod_index_t, while mod is the mask. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
ae576e85 | 2012-08-30 17:15:39 | state: remove unneeded optimization The code that follows does exactly that. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a45b7d75 | 2012-08-27 11:51:37 | state: light indicator when either condition is satisfied For the indicator to be set, it is sufficient for at least one of the group, modifier, or control state to match; this is in line with the xkblib spec, section 8.2 and ComputeAutoState() in xserver/xkb/xkbLEDs.c (though the xserver implementation differs from the spec on some points...). This also adds a tiny optimization to skip the entire check if the mask is empty. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
d1b476a3 | 2012-08-27 11:25:23 | state: fix led_update_all group mask calculation The one above uses which_mods, this one should use which_groups. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
87dff888 | 2012-08-10 18:14:35 | Store actions inside struct xkb_key Cuts out a lot of useless redirection and space. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
75853ed6 | 2012-08-10 10:11:49 | Use XKB_{GROUP,LEVEL}_INVALID instead of -1 for errors The group/level types are unsigned, so it's odd to return -1 for them. Instead use their invalid values (which happen to be == -1). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
6d61e39d | 2012-08-10 10:08:20 | state: use global static const for fake action Requires constifying some arguments. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
07b18bde | 2012-08-09 02:33:51 | Modernize struct xkb_mods Currently xkb_mods has the following members: - uint8_t real_mods - 8 X11 core mods - xkb_mod_mask_t vmods - 16 virtual mods, zero-based index - xkb_mod_mask_t mask - the computed effective *real* modifier mask, basically a cache for the first two which is: real_mods | real mods computed from vmods Our API acts on masks which combine the real_mods and vmods into a single value, which is: 8 first bits real mods | 16 next bits virtual mods (XkbNumModifiers = 8, XkbNumVirtualMods = 16). This is also the format which ResolveVModMask uses (which is where all the modifier masks really "come from", e.g. "Shift+Lock+Level5" -> xkb_mod_mask_t). What the code does now after getting the mask from ResolveVModMask, is to break it into real part and virtual part and store them seperately, and then join them back together when the effective mask is calculated. This is all pretty useless work. We change xkb_mods to the following: - xkb_mod_mask_t mods - usually what ResolveVModMask returns - xkb_mod_mask_t mask - the computed mask cache And try to consistently use the word "mods" for the original, non-effective mods and mask for the effective mods (which can only contain real mods for now, because things break otherwise). The separation is also made clearer. The effective masks are computed by UpdateModifiersFromCompat after all the sections have been compiled; before this the mask field is never touched; after this (i.e. map.c and state.c) the original mods field is never touched. This single execption to this rule is keymap-dump.c: it needs to print out only the original modifiers, not computed ones. This is also the reason why we actually keep two fields instead keeping one and modifying it in place. The next logical step is probably to turn the real mods into vmods themselves, and get rid of the distinction entirely (in a compatible way). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
59d947c9 | 2012-08-05 19:24:44 | Add and use xkb_level_index_t Several types are used over the code for shift levels; better to use just one. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
58f8d2c1 | 2012-07-20 17:09:49 | utils: remove Xfuncproto.h and use our own macros Add XKB_EXPORT to replace _X_EXPORT, and copy the definitions of _X_ATTRIBUTE_FOO as ATTR_FOO. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
50b25a12 | 2012-07-17 11:03:43 | Use xkb_group_index_t for group variables throughout Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
d0097f4e | 2012-07-15 15:55:34 | Pass around xkb_key's instead of keycodes This way we don't need to look up the key every time. We now only deal with keycodes in the public API and in keycodes.c. Also adds an xkb_foreach_key macro, which is used a lot. 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> | |
|
a52fb7e2 | 2012-07-15 11:37:54 | Convert indecipherable macros to inline functions This was fun. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
caca60f3 | 2012-07-15 01:45:34 | Move per_key_repeats and enabled_ctrls to keymap All of the per-key data and global flags are now visible directly in the keymap. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
50fef8eb | 2012-07-15 00:46:31 | Get rid of xkb_indicator Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9308a460 | 2012-07-17 10:20:15 | Run source tree through uncrustify .uncrustify.cfg committed for future reference also, but had to manually fix up a few things: it really likes justifying struct initialisers. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
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> | |
|
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> | |
|
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> | |
|
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> | |
|
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> | |
|
8fbd44fd | 2012-04-06 03:12:50 | Implicitly include config.h in all files The definitions in config.h should be available in all files an implementation detail; it can be included through the build system instead of having each file pull it every time. This is especially helpful with AC_USE_SYSTEM_EXTENSIONS, as _GNU_SOURCE and friends can have an effect by merely being defined, which can lead to some confusion if its effective for only half the files. And we don't really support a build _without_ config.h; so, one less thing to worry about. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
1b9635df | 2012-04-08 02:08:37 | Add xkb_state_get_map() This is very useful because it avoids redundent pointers in structs and/or parameter passing in the application. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
18e6a6a4 | 2012-04-05 10:47:43 | Remove Xfuncproto.h and XKB.h from xkbcommon/xkbcommon.h The kbproto header is already not needed here anymore. Move the _X_EXPORT's to the corresponding function definitions, and use straight extern "C" clauses instead of _XFUNCPROTOBEGIN/END. It also makes more sense to have the EXPORT's in the source files, as it provides some documentation to the reader, whereas in the header it's obvious. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated for xkb_keymap changes.] | |
|
467d7bb6 | 2012-04-05 10:13:24 | Implement missing xkb_state_ref and add return value xkb_state_ref was missing. Also modify the _ref functions to return the object instead of being void. This is a useful idiom: struct my_object my_object_new(struct xkb_state *state) { [...] my_object->state = xkb_state_ref(state); [...] } Essentially "taking" a reference, such that you don't forget to increment it and it's one line less (see example in our own code). A case could also be made for _unref to return the object or NULL, but this is quite uncommon. 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> | |
|
f0cb4ee2 | 2012-03-27 16:15:06 | Update xkb_filter_group_lock_func for xkb_key_direction Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
3fa7fdd0 | 2012-03-23 17:50:37 | Handle group lock actions The spec is simple here, as this action has no effect on key releases. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3b22373f | 2012-03-23 17:48:35 | Properly free xkb_state's 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> | |
|
83b8b4b5 | 2012-03-27 12:07:40 | Cosmetic coding style fixups 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> | |
|
504cc0b8 | 2012-03-22 14:31:33 | Check for invalid indices in mod/group state API 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> |