In particular, highlight the use of configure flags to control locating
X11 keyboard stuff when building for Wayland.
Of particular note, if the locale root is not specified, then xkbcommon
will look for them under $prefix (i.e. /usr/local/share/X11/locale).
But unless the user has specifically installed them there, it is better
to look in the standard system location, /usr/share/X11/locale.
Otherwise, xkbcommon will error when it can't find them, e.g.:
xkbcommon: ERROR: ~/.XCompose:4:9: failed to expand %L to the locale Compose file
xkbcommon: ERROR: ~/.XCompose:4:12: unterminated string literal
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Otherwise it can segfault e.g. running ./compose inside the bench
directory.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Signed-off-by: Ran Benita <ran234@gmail.com>
keymap was defined in the X11 example, but also define it in the wayland
example just to make it a bit more standalone
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
xkb_context_new() returns a xkb_context pointer, so change the variable
definition to be consistent.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Takes care of GCC's annoyingly persistent warn_unused_result warnings.
But it's better to avoid system() I suppose.
Signed-off-by: Ran Benita <ran234@gmail.com>
More meticulously free everything we create, including hooking up the
buffer-release callback so we actually free those when required. Make
sure seats are actually in the display's seat list.
The xkbcommon object-unref functions don't actually require
NULL-checking, so we can elide those.
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>
Looks like the CI machines can use Ubuntu 14.04, which has libxcb 1.10,
which is new enough. Lets see if it works.
Signed-off-by: Ran Benita <ran234@gmail.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>
fileno() can fail, if called on e.g. fmemopen() FILEs which are not
backed by a file descriptor. This functions uses mmap to map the entire
file to memory, so using such FILEs will not work.
(There is actually no change of behavior here, since the following fstat
would have already failed with EBADF. But lets make it clear.)
Another possibility is to fall back to the !HAVE_MMAP case; but it
sounds like a better idea to leave it to the programmer to use the
new_from_string/new_from_buffer functions instead, instead of doing
double allocation behind their back.
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>
Ran Benita
Bryce Harrington
Bryce Harrington
Daniel Stone
Mike Blumenkrantz