The ComputeEffectiveMap function is only called from keytypes.c, with
the last argument NULL, so we can move it there and remove some code.
The function XkbcVirtualModsToRealMods, of which the above is the only
user, is already implemented more simply in compat.c, so make this one
non-static and use it. This leaves src/xkb.c empty, so remove it.
Signed-off-by: Ran Benita <ran234@gmail.com>
commit 46441b1184 removed this from the
public API, and we don't need it internally. So send it to the archives.
Signed-off-by: Ran Benita <ran234@gmail.com>
To quote the spec:
XkbSI_AllOf
All of the bits that are on in mods must be set, but others may be
set as well.
Here "mods" refers to interp->mods. This matches xserver/libX11.
Signed-off-by: Ran Benita <ran234@gmail.com>
It doesn't play well with multiple keysyms per level right now. But
that's OK, because no-one really uses them.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We'd accidentally inverted silent vs. non-silent compilation, which
would skew the benchmark pretty badly, but also forgot to change base to
evdev for the rules here.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Readd the component names to the keymap->names struct. This is used when
printing the component, e.g.
xkb_keymap {
xkb_keycodes "evdev+aliases(qwerty)" {
instead of
xkb_keymap {
xkb_keycodes {
This makes diffing against xkbcomp $DISPLAY a bit easier and is kind of
useful anyway.
Signed-off-by: Ran Benita <ran234@gmail.com>
Evidently good to have on its own, but also fixes a regression from
xkbcomp where we'd identify implicitly-typed Cyrillic keys as TWO_LEVEL
rather than ALPHABETIC.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The code used to match a keysym to a keycode (see added comment)
differed in behavior from xkbcomp, always taking the first key it found.
This caused some incorrect interpretation of the xkeyboard-config data,
for example the one corrected in dump.data (see the diff): since the
de-neo layout sets the both_capslock option, the Left Shift key (LFSH)
has the Caps_Lock keysym in group 4 level 2; now since
keycode(Left Shift) = 50 < keycode(Caps Lock) = 64
the Left Shift one was picked, instead of the Caps Lock one which is
group 1 level 1. The correct behavior is to pick according to group,
level, keycode.
Signed-off-by: Ran Benita <ran234@gmail.com>
Use a self-contained dataset instead of relying on a globally-installed
set. Data taken from xkeyboard-config 2.5.1.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Including creating a context (will come in useful soon), opening and
reading files, and compiling keymaps.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Since BindIndicators was only ever called immediately after
CopyIndicatorMapDefs, move it up in the file and turn it into a static
function, which avoids the need to ever pass the unbound LEDs around.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
When we merge two KeyInfo's (belonging to the same keycode), we may take
a shortcut from copying if we see that the merged keys will be exactly
like those in one of the two KeyInfo's. In the case where we take the
symbols from the KeyInfo we are *not* merging into, we need to copy
the three arrays:
syms[group], symsMapNumEntries[group], symsMapIndex[group]
The code currently only copies the first one, so if there's a merge
conflict some levels may seem to disappear (i.e. have a NoSymbol
keysym).
This fixes the failing test added in c8d6bba.
Signed-off-by: Ran Benita <ran234@gmail.com>
For some reason, with the grp:alt_shift_toggle option, the following
sequence switches a group:
< Left Shift down, Left Alt down >
While the reverse doesn't:
< Left Alt down, Left Shift down >
And it should.
Signed-off-by: Ran Benita <ran234@gmail.com>
This was broken by commit 18d331b86b
(where only the first option out of a comma-separated string was
matched). Do it correctly this time and add a test.
Signed-off-by: Ran Benita <ran234@gmail.com>
This commit fixes the incorrect current behavior, where at the end of the
following key sequence
Left Shift down, Right Shift down, Left Shift up
the Shift modifier is cleared.
Clearly the code is not as nice as before, but it seems like some count
of the depressed modifiers must be kept.
The code is lifted mostly as is from xkbActions.c. [ There they also
assign to setMods and clearMods each time and not OR it. I assume its
correct, although I wouldn't have guessed... ]
Signed-off-by: Ran Benita <ran234@gmail.com>
This commit removes the ability to specify a keymap *in a rules file*,
e.g. in /usr/share/X11/xkb/rules/evdev or somesuch. This is unused in
xkeyboard-data, and the current code has never even supported it,
because xkb_map_new_from_kccgst (which is no longer exposed in the API)
checks to see that one of the usual components (e.g. symbols, types, ..)
has been filled, while the rules parser, on the other hand, doesn't
allow to specify a keymap and other stuff at the same time.
( The idea was to remove xkb_map_new_from_kccgst entirely, but it's used
by a test so it can stay. )
tl;dr: dead code. Of course passing a keymap file to
xkb_map_new_from_file still works.
Signed-off-by: Ran Benita <ran234@gmail.com>
compile_keymap can only be passes a single keymap file now, from all
code paths leading to it. So this function doesn't do anything.
The remaining check is performed inside CompileKeymap, so we can remove
it as well; compile_keymap doesn't do much now.
Signed-off-by: Ran Benita <ran234@gmail.com>
It seems like at some point it was needed to break the abstraction and
perform this piece of code in the context above CompileCompatMap. The
extra argument and the typedef look strange now, and doesn't seem to be
needed any more, so move them back.
Signed-off-by: Ran Benita <ran234@gmail.com>
enums are nice for some type safety and readability. This one also
removes the distinction between file type mask / file type index and
some naming consistency.
Signed-off-by: Ran Benita <ran234@gmail.com>
If we've only derived that a key should repeat, rather than had it
explicitly specified, don't set the explicit member. Fixes the dump
test.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
An entry for a type will only get marked as active if a virtual modifier
can be directly mapped to it, and not if an action indirectly leads to
it (e.g. LevelThree). We don't really need this test since entries which
can never be triggered ... won't be triggered.
The entire map->active thing should probably just go away.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Our early exit in ApplyInterpsToKey meant we weren't hitting the code
that's supposed to set a sensible default autorepeat value for most
keys.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This test verifies the core purpose of this library, which is to
translate the user's keypresses into keysyms according to the keymap and
the XKB specification.
The tests emulate a series of key presses, and checks that the resulting
keysyms are what we expect.
Several of the tests currently fail, and plenty more should be added and
maybe split up.
It also currently uses an RMLVO keymap, which comes from the
xkeyboard-config data set, and whose behaviour may change in the future.
So it should probably be changed to use several files of our own, but
it's OK for now.
Signed-off-by: Ran Benita <ran234@gmail.com>
For the darray we need to specify the explicit struct xkb_filter type
instead of void*, so we move the definition of struct xkb_state into
state.c thus making it opaque even from the rest of the files. It has
enough getters to get going and is otherwise good style.
Signed-off-by: Ran Benita <ran234@gmail.com>
The arrays found in KeyInfo are by far the most complicated, so this is
taken one member at a time so as not to break anything.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Daniel Stone