Bring the input file into line with recent changes to the dump output,
so we're as close as we can get to a round trip.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Right now it just comes from build-time, but eventually this should be
sourced from configuration files at runtime too.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Currently the user has no way of knowing which of the active modifiers
have been used in the translation of a keycode to its keysyms. The use
case is described in the GTK docs: say there's a menu accelerator
activated by "<Alt>+". Some layouts have "+" shifted, and some have it
on the first level. So in keymaps where "+" is shifted, the Shift
modifier is consumed and must be ignored when the user is testing
for "<Alt>+". Otherwise, we may get "<Alt><Shift>+" and the accelerator
should not actually fire.
For this we also use the preserve[] information in the key types, which
can forces us to report modifiers as unconsumed even if they were used
in the translation. Until now we didn't do anything with this
information.
The API tries to match its surronding. It's not very efficient but this
can be fixed.
Signed-off-by: Ran Benita <ran234@gmail.com>
If there is no map entry for some modifier combination, the default is
to use level 1. The removed code is an optimization to save some space
by removing these entries. But it doesn't actually save any space, and
did not in fact remove all level 1 entries (it walks the array while
modifying it so there's an off-by-one error).
We can instead keep them in the types but just not print them in
keymap-dump.c, to get about the same behavior.
Signed-off-by: Ran Benita <ran234@gmail.com>
Xkb required every keymap to have at least the four following canonical
types: ONE_LEVEL, TWO_LEVEL, ALPHABETIC, KEYPAD. This is specified in
e.g. the kbproto spec and XkbKeyTypesForCoreSymbols(3) man page.
If these types are not specified in the keymap, the code specifically
checks for them and adds them to the 4 first places in the types array,
such that they exist in every keymap. These are also the types (along
with some non-required 4-level ones) that are automatically assigned to
keys which do not explicitly declare a type (see FindAutomaticType in
symbols.c, this commit doesn't touch these heuristics, whcih are also not
very nice but necessary).
The xkeyboard-config does not rely on the builtin xkbcomp definitions of
these types and does specify them explicitly, in types/basic and
types/numpad, which are virtually always included.
This commit removes the special behavior:
- The code is ugly and makes keytypes.c harder to read.
- The code practically never gets run - everyone who uses
xkeyboard-config or a keymap based upon it (i.e. everyone) doesn't need
it. So it doesn't get tested.
- It mixes policy with implementation for not very good reasons, it
seems mostly for default compatibility with X11 core.
- And of course we don't need to remain compatible with Xkb ABI neither.
Instead, if we read a keymap with no types specified at all, we simply
assign all keys a default one-level type (like ONE_LEVEL), and issue
plenty of warnings to make it clear (with verbosity >= 3). Note that
this default can actually be changed from within the keymap, by writing
something like
type.modifier = Shift
type.whatever_field = value
in the top level of the xkb_types section. (This functionality is
completely unused as well today, BTW, but makes some sense).
This change means that if someone writes a keymap from scratch and
doesn't add say ALPHABETIC, then something like <AE11> = { [ q Q ]; }; will
ignore the second level. But as stated above this should never happen.
Signed-off-by: Ran Benita <ran234@gmail.com>
The program reads key events from evdev input devices, puts them through
the library and prints some information about them. It's nice for
experimenting, quick testing and trying to break it with random stuff
(already found some!).
It is called "interactive" for lack of a better name. It's a bit
hackish, but can easily be extended, made more portable etc, in the
future.
Signed-off-by: Ran Benita <ran234@gmail.com>
Conflicts:
Makefile.am
test/.gitignore
It's more tidy and less error prone, since we use strcasecmp == 0 a lot.
We replace strcmp == 0 by streq, strcasecmp == 0 by istreq,
uStrCasePrefix by istreq_prefix and uDupString by strdup_safe.
Signed-off-by: Ran Benita <ran234@gmail.com>
.uncrustify.cfg committed for future reference also, but had to manually
fix up a few things: it really likes justifying struct initialisers.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
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>
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>
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>
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>
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>
This code uses a table and code derived from
http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c
The added API calls are:
xkb_keysym_to_utf32
xkb_keysym_to_utf8
[daniels: Changed API to be more in line with keysym_get_name, added
test, changed formatting to 4-space.]
Add a test/dump.data file which contains the result we're expecting from
xkb_map_get_as_string run on a particularly complex set of keymaps, and
assert that the string representations are the same. This means that
any updates to xkb_map_get_as_string will also need to update the test
data, but should also ensure that we don't have any more parser
regressions.
Compared with diff to the output of setxkbmap + xkbcomp for the same
keymap; seems completely solid.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone
Ran Benita
Rob Bradford