The current functions dealing with consumed modifiers use the
traditional XKB definition of consumed modifiers (see description in the
added documentation). However, for several users of the library (e.g.
GTK) this definition is unsuitable or too eager. This is exacerbated by
some less-than-ideal xkeyboard-config type definitions (CTRL+ALT seems
to cause most grief...).
So, because we
- want to enable alternative interpretations, but
- don't want to expose too much internal details, and
- want to keep things simple for all library users,
we add a high-level "mode" parameter which selects the desired
interpretation. New ones can be added as long as they make some sense.
All of the old consumed-modifiers functions keep using the traditional
("XKB") mode. I mark xkb_state_mod_mask_remove_consumed() and as
deprecated without adding a *2 variant because I don't it is very useful
(or used) in practice.
Alternative modes are added in subsequent commits (this commit only adds
a mode for the existing behavior).
https://github.com/xkbcommon/libxkbcommon/issues/17
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
Ran Benita
Bryce Harrington
Bryce Harrington
Daniel Stone