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>
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>
Including creating a context (will come in useful soon), opening and
reading files, and compiling keymaps.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
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 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 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>
Ran Benita
Daniel Stone