Such as:
Compiling path: ./test/data/bad.xkb mapName:
==1300== Conditional jump or move depends on uninitialised value(s)
==1300== at 0x4E46166: HandleVModDef (vmod.c:90)
==1300== by 0x4E3FEC9: HandleKeyTypesFile (keytypes.c:1035)
==1300== by 0x4E3FBE1: HandleIncludeKeyTypes.constprop.11 (keytypes.c:387)
==1300== by 0x4E401DD: HandleKeyTypesFile (keytypes.c:1022)
==1300== by 0x4E3FBE1: HandleIncludeKeyTypes.constprop.11 (keytypes.c:387)
==1300== by 0x4E401DD: HandleKeyTypesFile (keytypes.c:1022)
==1300== by 0x4E4026F: CompileKeyTypes (keytypes.c:1150)
==1300== by 0x4E3DF9B: CompileKeymap (keymap.c:169)
==1300== by 0x4E465E9: compile_keymap (xkbcomp.c:205)
==1300== by 0x4E46BE4: xkb_compile_keymap_from_file (xkbcomp.c:290)
==1300== by 0x400B37: test_file (filecomp.c:47)
==1300== by 0x4008E3: main (filecomp.c:90)
==1300== Uninitialised value was created by a stack allocation
==1300== at 0x4E3FB3F: HandleIncludeKeyTypes.constprop.11 (keytypes.c:366)
Signed-off-by: Ran Benita <ran234@gmail.com>
If we can't find the component of the include file we're looking for,
make sure we don't return success when we meant failure, segfault, or
spectacularly leak everything.
Tested with incorrect component includes for keycodes, compat, symbols,
and types.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: David Herrmann <dh.herrmann@googlemail.com>
Which also involved moving the global symbol map to be per-key instead;
this should probably be split out into a separate commit.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of allowing only one keysym per level per group, do as the
external API indicates and allow multiples. The existing syntax is:
key <AD01> { [ q, Q ] };
where the new syntax is:
key <AD01> { [ q, Q, { H, E, L, L, O },
{ Y, E, S, space, T, H, I, S, space, I, S, space, D, O, G } };
to make the key in the extreme top left of the keyboard do pretty
surprising things in levels 3 and 4.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
All global state is removed from the parser and scanner.
This makes use of the standard facilities in Bison and Flex for
reentrant/pure scanner/lexer and location tracking.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated to current sources.]
Unify all the different Makefile.am into a single short top level one
(the test/Makefile.am file is left intact though).
This makes the build system simpler to look and should encourage
unifying more currently-disparate code.
Some further motivation can be found in this page:
http://www.flameeyes.eu/autotools-mythbuster/automake/nonrecursive.html
Signed-off-by: Ran Benita <ran234@gmail.com>
Since we have our own xkb_keysym_t type, it makes sense to have our own
NoSymbol value instead of the one from X11/X.h.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
i.e comparison of signed and unsigned values. These are mostly
harmless but fixing them allows to compile cleanly with -Wextra.
Signed-off-by: Ran Benita <ran234@gmail.com>
There are some cases where we must free a string with a const qualifier.
Add a macro UNCONSTIFY to trick the compiler into silencing the warning
in the cases where we know what we're doing.
Signed-off-by: Ran Benita <ran234@gmail.com>
And merge all the similar ones into the same name.
The u* prefix is chosen over the _Xkb prefix because it has more uses
throughout the codebase. But It should now be simple to choose a nice
prefix and stay consistent.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: fixed for the case where we have strcasecmp]
Some unused defines and geometry-removal leftovers (specifically the
file geom.c and the struct for the keyboard coordinates).
Signed-off-by: Ran Benita <ran234@gmail.com>
The recalloc function should be expressed in terms of bytes to match its
name. However uTypedRecalloc retains its type so nothing is changed.
Signed-off-by: Ran Benita <ran234@gmail.com>
Sorry if your libc doesn't have this, but it's not my problem.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: Ran Benita <ran234@gmail.com>
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>
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>
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>
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>
This needlessly occupies memory for the lifetime of the library, and
does not make a noticeable difference otherwise.
This rules file won't be loaded more than once in most cases anyway, so
just load it again when it happens.
Signed-off-by: Ran Benita <ran234@gmail.com>
This needlessly occupies memory for the lifetime of the library, and
does not make a noticeable difference otherwise.
Instead, just parse the same file again when it happens.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Daniel Stone