compat: small changes

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: remove support for "locking" field in sym interprets

This field is used in conjunciton with key behaviors, which we don't
support since c1ea23da5. This is also unused in xkeyboard-config.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: remove dead NoAutomatic code

The xkblib spec, table 7.1 (indicators), says:
XkbIM_NoAutomatic: Xkb does not automatically change the value of the
                   indicator based upon a change in the keyboard state,
                   regardless of the values for the other fields of the
                   indicator map.

xkbcomp (the real one) never actually implemented a way for an indicator
statement to set this flag, so it's just dead unused code. We definitely
don't want to implement it ourselves, so remove any mention of it.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: remove support for setting indicator index directly

The current code allows to set the "index" field in an indicator
statment's body. This would bind the indicator to the specified index,
instead of by name (which was declared previously in xkb_keycodes).
Doing this is a bad idea, for the same reasons as in 3cd9704, and is
also happily not used anywhere.

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

Now that 1fba6189e67 removed support for binding indicator maps by index
instead of name, we can remove some more magic which happens now: if an
indicator map specifies an indicator name which was not previously
declared in a 'indicator 5 = "Caps Lock"'-like statement in
xkb_keycodes, we do not assign it the next free index, but emit a
warning and ignore it. xkeyboard-config already declared all of its
indicators, and if someone doesn't, it's most likely a mistake.

Removing support of this allows to get rid of all the code which
performs this late-binding, and make the info->leds a darray instead of
a list.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: remove group compatibility

Group compatibility statements are like the following:
    group 3 = AltGr;
This currently results in:
    keymap->groups[2].mask = <real mod mapped from AltGr vmod>
And we don't do any thing with this value later. The reason it exists in
XKB is to support non-XKB clients (i.e. XKB support disabled entirely in
the server), which do not know the concept of "group", and use some
modifier to distinguish between the first and second keyboard layouts
(usually with the AltGr key). We don't care about all of that, so we can
forget about it.

One artifact of this removal is that xkb_map_num_groups no longer
works, because it counted through keymap->groups (this wasn't entirely
correct BTW). Instead we add a new num_groups member to the keymap,
which just hold the maximum among the xkb_key's num_groups. This also
means we don't have to compute anything just to get the number of
groups.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: use darray instead of list for interps

No need for a list here.

Signed-off-by: Ran Benita <ran234@gmail.com>
xkbcomp: seperate keymap-copying code from Compile functions

Signed-off-by: Ran Benita <ran234@gmail.com>
vmod: remove support for direct vmod -> real mod mapping

The current code supports statements such as:
    virtual_modifiers NumLock = Mod2;
This would set the mapping from the NumLock vmod to the Mod2 real mod
directly, without going through the virtualModifier field in an
interpret statement (in xkb_compat) or vmods field in a key statement
(in xkb_symbols).

This is undocumented, unused and complicates things, so remove it.

Signed-off-by: Ran Benita <ran234@gmail.com>
expr: move op_type/value_type_to_string functions to ast

Generally the enum-to-string function should appear where the enum is
defined.

Signed-off-by: Ran Benita <ran234@gmail.com>
vmod: remove support for resolving integer to virtual modifier

This is only relevant to the virtualModifier= statement in interpret
statements in xkb_compat. The current code allows to write e.g.
    virtualModifier = 4
to get the virtual modifier whose index happens to be 4 (possibly
declared in other files or sections, i.e. xkb_types). Doing this is
undeterministic, will break without notice, and not used anywhere.
Don't allow it.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: remove comparison of unsigned >= 0

clang warning.

Signed-off-by: Ran Benita <ran234@gmail.com>
state: fix led_update_all group mask calculation

The one above uses which_mods, this one should use which_groups.

Signed-off-by: Ran Benita <ran234@gmail.com>
state: lit indicator when either condition is satisfied

For the indicator to be set, it is sufficient for at least one of the
group, modifier, or control state to match; this is in line with the
xkblib spec, section 8.2 and ComputeAutoState() in xserver/xkb/xkbLEDs.c
(though the xserver implementation differs from the spec on some
points...).

This also adds a tiny optimization to skip the entire check if the mask
is empty.

Signed-off-by: Ran Benita <ran234@gmail.com>
state: lit indicators also when mods/group is zero

The xkblib spec says, e.g.:
    If groups is zero, the indicator is lit whenever the base keyboard
    group is zero.
    If groups is zero, the indicator is lit whenever the latched
    keyboard group is zero.
And likewise for the modifiers. This fix is just what
xserver/xkb/xkbLEDs.c:ComputeAutoState() does.

Signed-off-by: Ran Benita <ran234@gmail.com>
keymap-dump: write directly instead of using static buffer

Signed-off-by: Ran Benita <ran234@gmail.com>
xkbcomp: clean up compile_keymap function

We make the xkb_file_type enum sequential instead of masks, and then
we don't have to repeat the file types several times in the function.
Makes the code cleaner.

Signed-off-by: Ran Benita <ran234@gmail.com>
Move enum xkb_file_type to xkbcomp/ast.h

This is a more suitable place for this enum, since it's internal to
xkbcomp.

Signed-off-by: Ran Benita <ran234@gmail.com>