Will be deprecated in automake 2.0.
Replaced by AC_CONFIG_MACRO_DIR (already present) which is available
since autoconf 2.63.
Signed-off-by: Ran Benita <ran234@gmail.com>
To be consistent with the meson build; also makes more sense as doxygen
can generate more than html (though we currently are not doing that).
Signed-off-by: Ran Benita <ran234@gmail.com>
The change in d44ba48 removed -I$(top_builddir)/src/xkbcomp, but this is
needed in order to find the generated parser.h file which is put in the
build dir.
I also added -I$(top_builddir)/src in order to match the meson behavior.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/50
Signed-off-by: Ran Benita <ran234@gmail.com>
These scripts generate source code that is committed to git and hence do
not really belong in the build system. A maintainer runs them as needed.
Signed-off-by: Ran Benita <ran234@gmail.com>
A bit more manageable this way, and the other part of the target is
already using python.
The output is the same, except I removed the reference to Makefile.am.
Signed-off-by: Ran Benita <ran234@gmail.com>
Mutter only implements v6 now, and Weston also implements that. Port
interactive-wayland to this so people can keep on using it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
interactive-wayland is very similar to x11/xev, and dumps out as much
state as possible.
It provides no titlebar and a completely random cursor, but such is
life.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Instead of giving Doxygen a series of absolute paths to the source
files and a relative path to the output directory, run it from the
source directory with purely relative paths to the source files, and
give it an absolute path to the build directory.
This fixes the parsing of README.md with a separate build directory,
since the relative includes for doc/quick-guide.md and doc/compat.md
don't resolve otherwise. Doxygen's INCLUDE_PATH turns out not to fix
this either, since that's just a set of paths to open and parse, rather
than an analogue to cpp's -I.
Signed-off-by: Daniel Stone <daniels@collabora.com>
For some reason, the dumped keymap started repeating the two key types
FOUR_LEVEL_PLUS_LOCK and FOUR_LEVEL_KEYPAD. I need to investigate, but
let's disable it for now until I do (the problem would likely not be in
the xkbcommon - at most in the test itself).
Signed-off-by: Ran Benita <ran234@gmail.com>
xkb_keymap_key_by_name() allows finding a keycode from a given keyname and
is useful for generating keyboard events to use in regression tests
during CI
xkb_keymap_key_get_name() is the inverse of xkb_keymap_key_by_name()
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
[ran: some stylistic tweaks + another test case]
Signed-off-by: Ran Benita <ran234@gmail.com>
- Add the new files bench.c and bench.h to implement a timer module.
- Implement the module with clock_gettime(), mach_absolute_time(), or
gettimeofday(), depending on a given platform.
- Replace the time measurement code of the benchmark programs with the
functions of the module.
Some results from the benchmark (compilation of en_US.UTF-8/Compose):
$ grep 'model name' /proc/cpuinfo
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
$ uname -a
Linux ran 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux
$ ./test/compose bench
compiled 1000 compose tables in 7.776488331s
So according to the above benchmark and valgrind --tool=massif, an
xkb_compose_table adds an overhead of about ~8ms time and ~130KB
resident memory.
For contrast, a plain US keymap adds an overhead of ~3ms time and 90KB
resident memory.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
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>
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>
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>
We need to validate some UTF-8, so this adds an is_valid_utf8()
function, which is probably pretty slow but should work correctly.
Signed-off-by: Ran Benita <ran234@gmail.com>
Add two tests:
./test/interactive-x11
which is like test/interactive-evdev, but should behave exactly like your
X keyboard and react to state and keymap changes - in other words, just
like typing in xterm. Press ESC to exit.
./test/x11
which currently should only print out the same keymap as
xkbcomp $DISPLAY out.xkb
(modulo some whitespace and some constructs we do not support.)
Signed-off-by: Ran Benita <ran234@gmail.com>
These are function to create an xkb_keymap directly from XKB requests
to the X server. This opens up the possibility for X clients to use
xcb + xcb-xkb + xkbcommon as a proper replacement for Xlib + xkbfile for
keyboard support.
The X11 support must be enabled with --enable-x11 for now.
The functions are in xkbcommon/xkbcommon-x11.h. It depends on a recent
libxcb with xkb enabled. The functions are in a new libxkbcommon-x11.so,
with a new pkg-config file, etc. so that the packages may be split, and
libxkbcommon.so itself remains dependency-free.
Why not just use the RMLVO that the server puts in the _XKB_RULES_NAMES
property? This does not account for custom keymaps, on-the-fly keymap
modifications, remote clients, etc., so is not a proper solution in
practice. Also, some servers don't even set it. Now, the client just
needs to recreate the keymap in response to a change in the server's
keymap (as Xlib clients do with XRefreshKeyboardMapping() and friends).
Signed-off-by: Ran Benita <ran234@gmail.com>
This helps ensure we don't ship a library with undefined symbols, which
can easily happen with multiple inter-dependent DSOs.
Signed-off-by: Ran Benita <ran234@gmail.com>
This makes it easier to share the private functions in other DSOs
without relying (too much) on dead code elimination, exported symbols,
etc.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Daniel Stone
Mike Blumenkrantz
Kazunobu Kuriyama
Jasper Lievisse Adriaanse
Jan Engelhardt