We added a -fvisibilty=default to the libtest.la CFLAGS. When automake
sees that the CFLAGS are different from those of libxkbcommon.la, it
figures it should recompile all of the $(libxkbcommon_la_SOURCES),
instead of reusing the already-compiled object files.
But actually, the convenience library is not a shared object, it's just
used as an archive, thus the -fvisibility is entirely pointless. So
avoid the recompilations by just removing it.
Signed-off-by: Ran Benita <ran234@gmail.com>
Replace the dog-slow unneeded strncasecmp() with an inlineable memcmp().
Before:
compiled 2500 keymaps in 8.348715629s
After:
compiled 2500 keymaps in 7.872640338s
Signed-off-by: Ran Benita <ran234@gmail.com>
The "width" terminology comes from the group*width+level layout of the
keysyms in a key, as used in the old implementations. We don't keep all
the keysyms of a key in one array so change it to a more accurate name.
Signed-off-by: Ran Benita <ran234@gmail.com>
It's easier to quickly go through the functions in a module this way.
The names provide enough "brief description" to get someone to click for
the full description.
Signed-off-by: Ran Benita <ran234@gmail.com>
An mlvo can also be used in an expansion, but we didn't mark them in
this case in commit d8a4f52cb9. This caused wrongful warnings on
something like -l ch -v fr -- the `fr` is only added via expansion.
Signed-off-by: Ran Benita <ran234@gmail.com>
Due to wildcard matches in the rules file, this is only really useful
for misspelled or missing options, e.g.
$ ./test/rmlvo-to-kccgst -o comprose:ralt > /dev/null
xkbcommon: ERROR: Unrecognized RMLVO option "comprose:ralt" was ignored
Although it is more of a warning, it indicates a misconfiguration which
the user probably wants to see. Therefore the log level is ERROR.
Signed-off-by: Ran Benita <ran234@gmail.com>
Remove the deprecated symbols that were used for ABI compatibility
during the transition period to the first stable version, 0.2.0.
The old *names* can still be used, programs which use the old names will
continue to work, as long as they were compiled against a stable
version (as they have been #defined to the new names from the start; see
xkbcommon/xkbcommon-compat.h). Namely, this will break binaries which:
1. Were compiled against a pre-stable version of libxkbcommon, and
2. Are linked against the next version of libxkbcommon, and
3. Expect to work.
This scenario is very unlikely, and will break in many other ways
anyway. Also, retaining support for these means including them in the
new symbol version file, which I would like to avoid.
Signed-off-by: Ran Benita <ran234@gmail.com>
Symbol versions provide a means by which ELF utilities can determine
whether a program is incompatible with a too-old library version so
that package management tools can autodetect version-based
dependencies and suggest upgrade paths.
[ran: swap xkbcommon.map and xkbcommon-x11.map]
Signed-off-by: Jan Engelhardt <jengelh@inai.de>
Signed-off-by: Ran Benita <ran234@gmail.com>
If the keymap doesn't have any key-aliases (which is certainly
possible), the calloc(num_key_aliases, ...) is allowed to return NULL
according to the C standard, but this is not an error.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
libxkbcommon 0.4.3 introduces a new test, x11comp, which does not build
on non-Linux OSes because of the unconditional <linux/input.h> include.
This seems not needed even on Linux, so attached there is a simple patch
to remove it.
https://bugs.freedesktop.org/show_bug.cgi?id=83551
Signed-off-by: Ran Benita <ran234@gmail.com>
If Xvfb is not present, posix_spawn still forks, but the child fails.
In that case, since we left the write fd of the pipe open in the parent,
we just kept waiting on the read() without noticing that the other side
is dead.
Signed-off-by: Ran Benita <ran234@gmail.com>
The @level argument is restricted by xkb_keymap_num_levels_for_key(). Fix
the description to no longer mention xkb_keymap_num_layouts_for_key().
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Virtual modifiers can have "mappings" to real modifiers, e.g. NumLock
may also set Mod2. In a normal turn of events, the various components
(depressed, latched, locked, and consequently effective) include the
mapped mods, because the masks are pre-resolved everywhere. However,
xkb_state_update_mask() accepts arbitrary mod masks, which may not be
resolved (if it comes from somewhere other than
xkb_state_serialize_mods()). So let's always resolve them ourselves.
Signed-off-by: Ran Benita <ran234@gmail.com>
It is like test/stringcomp, only instead of using
xkb_keymap_new_from_string(), it uses xkbcomp to upload the keymap to a
dummy Xvfb X server and then xkb_x11_keymap_new_from_device().
If any of these components are not present or fails, the test is shown
as skipped.
The test is messy, fragile, limited and depends on external tools, but I
will improve on that later -- it's better to have a test.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Jan Engelhardt
Pino Toscano
Michael Forney
David Herrmann