keymap: use our type for keymap->enabled_ctrls

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: remove unneeded optimization

The levels will be resized to the number of levels of the type anyway,
so removing useless levels from the end here is unneeded.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: fix index-out-of-bounds in FindAutomaticType

If we enter this branch, we have 3 <= width <= 4, so if the width is 3
than syms[3] is out of bounds.

Happily inherited from xkbcomp.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: move keysyms into LevelInfo

Instead of maintaining a syms array in the GroupInfo + sym_index's in
the levels. This simplifies the code somewhat.
In order not to alloc for every level instead of every group, we only do
it if the level has more than one keysym (with a union). Since for now
this is a special case, it actually works out better memory-wise.

Signed-off-by: Ran Benita <ran234@gmail.com>
keymap, symbols: improve xkb_key memory layout

Add struct xkb_group and xkb_level for use in xkb_key, to mirror how
it's done in KeyInfo, GroupInfo, LevelInfo in symbols.c. This
corresponds more nicely to the logical data layout (i.e. a key has
groups which have levels), and also removes a lot of copying and ugly
code due to the index indirections and separate arrays which were used
before.

This uses more memory in some places (e.g. we alloc an action for every
level even if the key doesn't have any) but less in other places (e.g.
we no longer have to pad each group to ->width levels). The numbers say
we use less overall.

Signed-off-by: Ran Benita <ran234@gmail.com>
keymap: store a pointer to the type in xkb_group instead of index

Gets rid of some more unneeded indirection, including the XkbKeyType
macro.

Signed-off-by: Ran Benita <ran234@gmail.com>
keymap: remove some more unneeded macros

It clearer to just access the needed data directly.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: separate type-finding logic from CopySymbolsDef

It's easier to follow this in isolation. Besides, previously the error
reporting wasn't done very well.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: get rid of autoType

The autoType variable is supposed to tell us whether the type was
explicitly specified by the user or was detected automatically according
to the keysyms. It then allows us to know whether to prints the type
when we dump the keymap to a string or not.

Right now it is not always set when we find an automatic type, according
to some apparently legacy rules. We change it to simply this: type
computed automatically? -> don't print.

Signed-off-by: Ran Benita <ran234@gmail.com>
Fix size_t vs. %d warning

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Add xkb_state_key_get_one_sym

The trivial wrapper around xkb_state_key_get_syms that every user to
date has implemented.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
state: add missing const in get_one_sym

Signed-off-by: Ran Benita <ran234@gmail.com>
xkbcomp/keymap: use default interpret in ApplyInterpsToKey

This makes the code easier to follow and does more explicitly what the
xkblib spec says:
     If no matching symbol interpretation is found, the server uses a
     default interpretation where:
        sym =	0
        flags =	XkbSI_AutoRepeat
        match =	XkbSI_AnyOfOrNone
        mods =	0
        virtual_mod =	XkbNoModifier
        act =	SA_NoAction

If a level doesn't have any keysyms, we don't apply anything to it.

Signed-off-by: Ran Benita <ran234@gmail.com>
Don't limit key names to 4 characters

Currently you can't give a key in xkb_keycodes a name of more than
XKB_KEY_NAME_LENGTH (= 4) chars. This is a pretty annoying and arbitrary
limitation; it leads to names such as <RTSH>, <COMP>, <PRSC>, <KPAD>
etc. which may be hard to decipher, and makes it impossible to give
more standard names (e.g. from linux/input.h) to keycodes.

The purpose of this, as far as I can tell, was to save memory and to
allow encoding a key name directly to a 32 bit value (unsigned long it
was).

We remove this limitation by just storing the names as atoms; this lifts
the limit, allows for easy comparison like the unsigned long thing, and
doesn't use more memory than previous solution. It also relieves us from
doing all of the annoying conversions to/from long.

This has a large diffstat only because KeyNameText, which is used a lot,
now needs to take the context in order to resolve the atom.

Signed-off-by: Ran Benita <ran234@gmail.com>
Fix type of keycode in parser and ast

For some reason keycodes were listed under mapFlags in the yylval union.
Fix it and some sanity checks.

Signed-off-by: Ran Benita <ran234@gmail.com>
test/interactive: allow to set evdev offset

If we want to test a keymap without the usual 8 offset.

Signed-off-by: Ran Benita <ran234@gmail.com>
keymap-dump: make it look better with long key names

Not worth messing around with too much, just make it legible.

Signed-off-by: Ran Benita <ran234@gmail.com>
test: add keycodes files which map directly to evdev codes

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>