GCC complained:
misc.c:235:13: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]
misc.c:248:13: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]
Looking at keysymdef.h shows that the check is indeed wrong. This commit
updates the check to match the latin8 section of keysymdef exactly.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
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>
This resulted in duplicate sets of modifiers, since we were comparing
pointer equality of two strings, rather than string equality. Oops.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
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>
Previously, we would clear out the real modmask when updating the
modmask for action maps, if not using the key's modmask. The correct
behaviour here is instead to use the key's modmask if using the modmap,
else use the real mods provided with the action originally.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Unfortunately we can't get the actual file it was defined in this far
down, but at least give the human-readable name rather than just a group
index.
Also, groups are not zero-indexed, such that index 0 is group 1; fix
that too.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of generating a fairly droll internal error, generate a warning
also telling us exactly where the bad definition was.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
By ensuring their mask is only the vmods, rather than also potentially
including the key's modmap. Also remove the unnecessary vmodmask
indirection.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Add the dump of my full current X11/XKB keymap as a test for filecomp,
being as it also includes geometry.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The server used to have to go and do this on our own, but we can do
better than that: after we've compiled the keymap, go through and bind
virtual modifiers to everything that needs it.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Right now we just silently ignore overlay controls, which is probably
bad, but it's not the easiest to fix.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
It looks like this could never have worked anyway, what with num_rg
always being 0 everywhere. Remove it.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The XkbKey* macros used to work through XkbCM* and XkbSM* variants, for
the xkb_map and xkb_server_map respectively; the latter versions weren't
used by anyone at all, so just bin them and make the macros work
directly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita
Guillem Jover
Daniel Stone