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>
They're no longer needed since we don't expose any atoms in the
published API anymore. As a result, we don't need to support external
atom implementations either. Result!
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ironically, the test for named.xkb included a call that relied on the
default keymap, without the file naming an explicit default. Go figure.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
On many layouts, the following error appears:
Internal error: Could not resolve keysym 10005b0
(Which is like the trademark of libxkbcommon now, and makes
unicode-heavy symbol files pretty useless).
This occurs when a keysym string (in this case, 10005b0) is passed to
xkb_string_to_keysym, but cannot be resolved.
This in turn happens because the parser passes on hexadecimal keysym
strings without the leading "0x", thus leaving the resolving function
without a way to disambiguate it as a number.
Therefore, make sure to pass on the "0x". The file symbols.c in xkbcomp
project does the same; it probably got lost in translation.
Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone
Ran Benita