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>
Our current code (taken from the xserver) doesn't handle unicode keysyms
at all, and there seem to be some other changes compared to libX11,
which is what xkbcomp uses. So we just copy the code that does that from
libX11.
It would be much better to not have to hardcode unicode tables like
that, but it's probably better than dealing with glibc locale stuff for
now. It also doesn't affect our binary size much.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is a regression introduced in ed78fbcb30.
XKB_STATE_EFFECTIVE is just a OR of the other states, so using & here is
completely wrong. So test/state shows for example:
dumping state for LCtrl down:
group English (US) (0): effective depressed latched locked
mod Control (2): depressed latched locked
dumping state for LCtrl + RAlt down:
group English (US) (0): effective depressed latched locked
mod Control (2): depressed latched locked
mod Mod1 (3): depressed latched locked
dumping state for RAlt down:
group English (US) (0): effective depressed latched locked
mod Mod1 (3): depressed latched locked
dumping state for Caps Lock:
group English (US) (0): effective depressed latched locked
mod Lock (1): depressed latched locked
led Caps Lock (0): active
dumping state for Alt-Shift-+
group English (US) (0): effective depressed latched locked
mod Shift (0): depressed latched locked
mod Mod1 (3): depressed latched locked
which is bogus.
Signed-off-by: Ran Benita <ran234@gmail.com>
This rule allows you to put several xkb_keymaps in one file.
This doesn't make any sense: only the default/first can ever be used,
yet the others are fully parsed as well.
Different keymaps should just be put in different files.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is a proof-of-concept for the long key names. The keycodes in the
file evdev-xkbcommon are autogenerated from linux/input.h, and uses the
names given there; all of the previous names are aliased to the new
names, so they continue to work with the symbols files, etc.
You can try it with 'sudo ./test/interactive -r evdev-xkbcommon -n 0'
The -n 0 means that we don't offset the evdev scan codes - just feed
them directly. The -r evdev-xkbcommon just means to use a new rules file
which makes us use the new keycodes file. (The only problem I can see is
with the MENU and LSGT names which has some conflicts).
Maybe some day xkeyboard-config could ship something similar, so that
the 8 offset is unneeded.
Signed-off-by: Ran Benita <ran234@gmail.com>
This function really needs a format argument, for symmetry with the
keymap creation functions. If we add new formats, we will almost
certainly want to add support for serializing it into a string. It would
also allow to convert from one format to another, etc.
The in the common case, the user would just want to use the format she
used to create the keymap; for that we add a special
XKB_KEYMAP_USE_ORIGINAL_FORMAT value, which will do that (it is defined
to -1 outside of the enum because I have a feeling we might want to use
0 for something else). To support this we need to keep the format inside
the keymap. While we're at it we also initialize keymap flags properly.
This changes the API, but the old xkb_map_get_as_string name works as
expected so this is the best time to do this.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is to follow the general scheme set by all of the other API
functions.
Since no one is using these functions yet, we don't (actually better
not) add the old names to xkbcommon-compat.h.
Signed-off-by: Ran Benita <ran234@gmail.com>
These values weren't wrapped before, which caused group_index_is_active
to stop working after a few group switches.
Also, the current group-wrapping function didn't take into consideration
actions such as LockGroup=-1, which need to wrap around, etc.
xkb_layout_index_t is unsigned, but it was used to hold possibly
negative values (e.g. locked_group is 0 and gets a -1 action).
This group wrapping function should now act like the XkbAdjustGroup
function from xserver, and at least ./test/interactive doesn't bring up
any problems with group switching any more.
Signed-off-by: Ran Benita <ran234@gmail.com>
This old rules parser gives the same kccgst here, so in the interest of
staying compatible we shouldn't fix it there. Similarly we shouldn't
touch ParseIncludeMap, so this is the best place to handle this.
Signed-off-by: Ran Benita <ran234@gmail.com>
This just prints the compiled keymap string for to the given command
line arguments. This often useful when developing.
Signed-off-by: Ran Benita <ran234@gmail.com>
Trying ''./test/interactive -l us:5' causes us to crash.
The <layout>:<N> syntax says to put this layout at the N'th level.
However the code (inherited from xkbcomp) doesn't check that the group
is valid, and then happily indexes keyi->groups with it, which has a
static size of XKB_NUM_GROUPS (the SetExplicitGroup function assumes the
index is valid). So any value a user might put there > 4 makes nice
things happen.
Signed-off-by: Ran Benita <ran234@gmail.com>
e.g. hhhhhHHHHHHHhhhhhh with shift down and up in the middle.
Unfortunately trying a quick test with test/interactive is not possible
because the evdev soft-repeat stops the repeat when another key is
pressed. So you need real soft-repeat for that.
Signed-off-by: Ran Benita <ran234@gmail.com>
- Add context.h and move context-related functions from xkb-priv.h to
it.
- Move xkb_context definition back to context.c.
- Add keysym.h and move keysym upper/lower/keypad from xkb-priv.h to it.
- Rename xkb-priv.h to map.h since it only contains keymap-related
definitions and declarations now.
- Remove unnecessary includes and some and some other small cleanups.
Signed-off-by: Ran Benita <ran234@gmail.com>
These statements are pretty pointless for us; we don't restrict keycodes
like X does, and if someone writes e.g. maximum = 255 but only has 100
keys, we currently happily alloc all those empty keys. xkbcomp already
handles the case when these statements aren't given, and uses a computed
min/max instead. We should just always use that.
(Of course since keycodes/evdev currently uses almost all of the
keycodes in the range it declares, including 255, this doesn't save any
memory for the common user right now).
Signed-off-by: Ran Benita <ran234@gmail.com>
This layout stretches us pretty well, so it's good for testing nothing
breaks. There are a couple of things that need looking into, though
(particularly the level5 issue).
Signed-off-by: Ran Benita <ran234@gmail.com>
Background:
The CopySymbolsDef has a comment on a couple of lines which supposedly
fixed a bug:
/*
* kt_index[i] may have been set by a previous run (if we have two
* layouts specified). Let's not overwrite it with the ONE_LEVEL
* default group if we dont even have keys for this group anyway.
*
* FIXME: There should be a better fix for this.
*/
if (!darray_empty(groupi->levels))
key->kt_index[i] = types[i];
But neither the comment nor the fix make any sense, because the kt_index
is indexed per group, i.e. each group gets its own type.
The original xkbcomp commit which added this (36fecff58) points to this
bug: https://bugzilla.redhat.com/show_bug.cgi?id=436626
which complains about -layout "ru,us" -variant "phonetic," not working
properly. And indeed when we try:
sudo ./test/interactive -l ru,us -v
the first group doesn't get any syms for the main keys.
The problem (Clearly the fix above is useless):
The ru(phonetic) map is specified using aliases, e.g. LatQ, LatW instead
of AD01, AD02, etc. When combined with another layout which uses the
real names (AD01, AD02), the symbols code should recognize they are the
same key and merge them into one KeyInfo. The current code does that,
but it doesn't catch the case where the alias was processes *before* the
real one; so we get two KeyInfo's and the later one wins. So e.g. the
ru(phonetic) symbols are ignored.
The fix:
Before adding a new KeyInfo to the keys array, always replace its name
by the real name, which avoids the entire issue. Luckily this is done
pretty late so most error messages should still show the alias name.
Signed-off-by: Ran Benita <ran234@gmail.com>
With Dan Nicholson's permission (via email), update his copyright and
license statements to the standard X.Org boilerplate MIT license, as
both myself and Ran have been using.
Clean up my copyright declarations (in some cases to correct ownership),
and add copyright/license statements from myself and/or Ran where
appropriate.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
There are two ways to separate multiple files in XKB include statements:
'+' will cause the later file to override the first in case of conflict,
while '|' will cause it augment it (this is done by xkbcomp). '!' is
unrelated here.
Since '|' is practically never used, this wasn't noticed.
In the modified test, the '|some_compat' previously was just ignored.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
David Herrmann
Daniel Stone