The xkbproto spec says:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Lock_Modifier
If the Lock modifier is not consumed by the symbol lookup process,
routines that determine the symbol and string that correspond to
an event should capitalize the result.
This was not an issue until now, because most xkeyboard-config keymaps
do not utilize this "feature", and specify the keysyms for the Lock
modifier explicitly instead. However, some keymaps do depend on it, e.g.
ch(fr) for eacute and others.
The spec goes on to describe two options for doing this transformation:
locale-sensitive and locale-insensitive. We opt for the latter; it is
less desirable but we don't want *that* headache.
Also, only xkb_state_key_get_one_sym() is changed;
xkb_state_key_get_syms() is left as-is, and always reports the
untransformed keysyms. This is for the following reasons:
- The API doesn't allow it, since we return a const pointer directly to
the keymap keysyms table and we can't transform that.
- The transformation doesn't make sense for multiple-keysyms.
- It can be useful for an application to get the "raw" keysyms if it
wants to (e.g. maybe it wants to do the transformation itself).
Finally, note that xkb_state_mod_index_is_consumed() does *not*
report Lock as consumed even if it was used in the transformation. This
is what Xlib does.
This definitely doesn't fall under the "hard to misuse" API rule but
it's the best we can do.
https://bugs.freedesktop.org/show_bug.cgi?id=67167
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Kind of odd, but get_one_sym() will be getting a different behavior.
Real life users *should* pick one or the other.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is too strict, and causes symbols/cz to fail parsing. Instead, just
emit a warning (not shown by default):
xkbcommon: WARNING: cz:75:19: unknown escape sequence in string literal
https://bugs.freedesktop.org/show_bug.cgi?id=68056
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Some keymaps actually have this, like the quartz.xkb which is tested. We
need to support these.
https://bugs.freedesktop.org/show_bug.cgi?id=67654
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
We should handle empty xkb_keycode and xkb_symbol sections, since
xkbcomp handles them, and apparently XQuartz uses it. There are also
files for it in xkeyboard-config (rules=base model=empty layout=empty,
which translate to keycodes/empty and symbols/empty).
https://bugs.freedesktop.org/show_bug.cgi?id=67654
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
PATH_MAX is optional in POSIX, so avoid its unconditional usage
allocating and freeing buffers as needed.
To avoid too many malloc/free in the for loop in FindFileInXkbPath,
a buffer is grown according to the size needed at each iteration.
Needed for some tests. The tests need some adjustment, mostly because of
the resolution of xkeyboard-config bug
https://bugs.freedesktop.org/show_bug.cgi?id=50935
Also add the 'ch' symbols file for future tests.
Signed-off-by: Ran Benita <ran234@gmail.com>
This ensures the names are escaped before having any interaction with
the user.
This was caught by noticing dump(compile(dump())) != dump. Since that's
a nice test we add it to stringcomp.
https://bugs.freedesktop.org/show_bug.cgi?id=67032
Reported-By: Auke Booij
Signed-off-by: Ran Benita <ran234@gmail.com>
Add three new pieces of API:
- xkb_keymap_min_keycode does what it says on the tin
- xkb_keymap_max_keycode likewise
- xkb_keymap_key_for_each calls the provided function once for every
valid key in the keymap
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If the keycode range is smaller than 8 → 255, artifically widen it when
dumping the keymap as not to displease X.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The current API doesn't allow the caller to create keymaps from mmap()'ed
files. The problem is, xkb_keymap_new_from_string() requires a terminating
0 byte. However, there is no way to guarantee that when using mmap() so a
user currently has to copy the whole file just to get the terminating zero
byte (assuming they cannot use xkb_keymap_new_from_file()).
This adds a new entry xkb_keymap_new_from_buffer() which takes a memory
location and the buffer size in bytes.
Internally, we depend on yy_scan_{string,byte}() helpers. According to
flex documentation these already copy the input string because they are
wrappers around yy_scan_buffer().
yy_scan_buffer() on the other hand has some insane requirements. The
buffer must be writeable and the last two bytes must be ASCII-NUL. But the
buffer may contain other 0 bytes just fine.
Because we don't want these constraints in our public API,
xkb_keymap_new_from_buffer() needs to create a copy of the input memory.
But it then calls yy_scan_buffer() directly. Hence, we have the same
number of buffer-copies as with *_from_string() but without the
terminating 0 requirement.
The explicit yy_scan_buffer() call is preferred over yy_scan_byte() so the
buffer-copy operation is not hidden somewhere in flex.
Maybe some day we no longer depend on flex and can have a zero-copy API. A
user could mmap() a file and it would get parsed right from this buffer.
But until then, we shouldn't expose this limitation in the API but instead
provide an API that some day can work with zero-copy.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
[ran: rebased on top of my branch]
Conflicts:
Makefile.am
src/xkbcomp/xkbcomp.c
Previously we allowed you to pass a names struct with five NULL members,
but not just pass NULL for the struct itself. This was pretty dumb. :(
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
You can now set default values in the environment, as well as a context
option to ignore the environment, e.g. for tests.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some tests use linux/input.h (and epoll), but we're building on some
other kernels (e.g. debian freebsd). We could just copy the file but
it's GPL. We could also skip the tests (exit code 77) but it doesn't
really matter.
Signed-off-by: Ran Benita <ran234@gmail.com>
Make it a bit easier to experiment with other formats.
Add a struct xkb_keymap_format_operations, which currently contains the
keymap compilation and _get_as_string functions. Each format can
implement whatever it wants from these.
The current public entry points become wrappers which do some error
reporting, allocation etc., and calling to the specific format. The
wrappers are all moved to src/keymap.c, so there are no XKB_EXPORT's
under src/xkbcomp/ anymore.
The only format available now is normal text_v1.
This is all not very KISS, and adds some indirection, but it is helpful
and somewhat cleaner.
Signed-off-by: Ran Benita <ran234@gmail.com>
xkbcomp doesn't indent there, so it's easier to diff.
Also saves some horizontal space which is sorely needed when looking at
these files (especially the xkb_symbols).
Signed-off-by: Ran Benita <ran234@gmail.com>
Recent xkeyboard-config introduced the following line in symbols/level3:
vmods = LevelThree,
However, the XKM format which xkbcomp produces for the X server can't
handle explicit virtual modifiers such as this:
https://bugs.freedesktop.org/show_bug.cgi?id=4927
So by doing the following, for example:
setxkbmap -layout de (or another 3-level layouts)
xkbcomp $DISPLAY out.xkb
xkbcomp out.xkb $DISPLAY
The modifier is lost and can't be used for switching to Level3 (see the
included test).
We, however, are affected worse by this bug when we load the out.xkb
keymap. First, the FOUR_LEVEL_ALPHABETIC key type has these entries:
map[None] = Level1;
map[Shift] = Level2;
map[Lock] = Level2;
map[LevelThree] = Level3;
[...]
Now, because the LevelThree virtual modifier is not bound to anything,
the effective mask of the "map[LevelThree]" entry is just 0. So when
the modifier state is empty (initial state), this entry is chosen, and
we get Level3, instead of failing to match any entry and getting the
default Level1.
The difference in behavior from the xserver stems from this commit:
acdad6058d
Which removed the entry->active field. Without bugs, this would be
correct; however, it seems in this case we should just follow the
server's behavior.
The server sets the entry->active field like so in XKBMisc.c:
/* entry is active if vmods are bound */
entry->active = (mask != 0);
The xkblib spec explains this field, but does not specify how to
initialize it. This commit does the same as above but more directly.
Signed-off-by: Ran Benita <ran234@gmail.com>
Sync the files again from xkeyboard-config 2.8, since there have been
some changes we should test against.
Also added a script test/data/sync.sh if we want to do it again in the
future.
Signed-off-by: Ran Benita <ran234@gmail.com>
The keysym2ucs.c file apparently leaves out some keysyms, which libX11
deals with separately (like in _XkbHandleSpecialSym()).
The problematic keysyms are the keypad ones (for which we already added
some support) and keysyms which use 0xff** instead of 0x00** < 0x20.
This code should fix them properly, as much as I could gather from
libX11 and http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c and other
sources (which are not aware of locale).
https://bugs.freedesktop.org/show_bug.cgi?id=56780
Reported-by: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
For error handling code, it's nice to be able to pass NULL to these
function without worrying about segfaults ensuing. free() sets the
precedent here.
Also document this fact.
Signed-off-by: Ran Benita <ran234@gmail.com>
This runs a bunch of random keys against xkb_state_update_key() and
xkb_state_key_get_one_sym(), in a fairly unintelligent way.
It might be nice to check when modifying this code path, or changing it,
to see things haven't slowed down considerably. However, given the
numbers this benchmark gives, it is pretty clear that we are not going
to be the bottleneck for anything. So this can more-or-less be ignored.
Incidentally, this also turned out to be a poor man's fuzzer, because it
turned up the fix in the previous commit. Maybe we should consider
beefing it up with an actual 'break stuff' intention and running it as
part of 'make check'.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is the more appropriate for a specific key (also considering the
num_layouts() is a bit of a made-up value).
Signed-off-by: Ran Benita <ran234@gmail.com>
Note first:
This commits breaks the ABI somewhat. If an application is run against
this commit without recompiling against the updated header, these break:
- xkb_state_layout_*_is_active always retuns false.
- xkb_state_serialize_mods always returns 0.
So it might break layout switching in some applications. However,
xkbcommon-compat.h provides the necessary fixes, so recompiling should
work (though updating the application is even better).
Split the enum to its individual components, which enables us to refer
to them individually. We will use that later for reporting which
components of the state have changed after update.
Signed-off-by: Ran Benita <ran234@gmail.com>
This adds a flags argument to xkb_keysym_from_name() so we can perform a
case-insensitive search. This should really be supported as many keysyms
have really weird capitalization-rules.
However, as this may produce conflicts, users must be warned to only use
this for fallback paths or error-recovery. This is also the reason why the
internal XKB parsers still use the case-sensitive search.
This also adds some test-cases so the expected results are really
produced. The binary-size does _not_ change with this patch. However,
case-sensitive search may be slightly slower with this patch. But this is
barely measurable.
[ran: use bool instead of int for icase, add a recommendation to the
doc, and test a couple "thorny" cases.]
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Currently xkb_keymap_num_leds() returns a count of valid (settable)
leds. Because the indexes might be non-consecutive, and some leds
might not be settable, it is incorrect to use this function for
iterating over the leds in the keymap. But this is the main use case of
this function, so instead of the current behavior we adapt the function
to the use case by making it return the needed range of iteration.
The caller needs to handle invalid intermittent indexes, though.
Signed-off-by: Ran Benita <ran234@gmail.com>
xkb_keymap_num_leds() returns the number of leds that have any
possibility of being set. Even if a led is defined but can not be set in
any way, it is not counted.
In a few places currently we assume that led indexes are smaller than
this number, which is wrong both for the above reason and for the fact
that the xkb format actually allows explicitly setting the indicator
index, which means that the indexes might be non-consecutive.
We don't really have good API to iterate on leds, now, because
xkb_keymap_num_leds is pretty useless. To work around that we use
sizeof(xkb_led_mask_t) * 8.
This makes the "Group 2" led work (try switching to a layout other than
the first in test/interactive).
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Pino Toscano
Matthias Clasen
Daniel Stone
David Herrmann
David Herrmann