types: add a general overview

Signed-off-by: Ran Benita <ran234@gmail.com>
types: don't use canonical/required types

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>
Remove xproto build dependency

Very little left to do for this.

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

Just make things easier to follow, no functional changes.

Signed-off-by: Ran Benita <ran234@gmail.com>
Fix virtual modifiers mask extraction

The calculations were performed incorrectly in several places,
specifically shifting by 16 instead of 8 (= XkbNumModifiers) and masking
with 0xff instead of 0xffff.

More stuff that probably never worked as intended. This also makes these
more grep-able when we remove the vmods/real_mods separation.

Signed-off-by: Ran Benita <ran234@gmail.com>
types: move preserve directly into xkb_kt_map_entry

Currently each xkb_key_type has a preserve array, which is only allocated
if a preserve[] statement is specified in the type. In this case each map
entry has an element in the array.

The space savings are negligible; put this field where it logically
belongs.

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

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>
types: use regular array for types

The current code doesn't resize it any more.

Signed-off-by: Ran Benita <ran234@gmail.com>
types: use regular array for map entries

This array is only initialized once.

Signed-off-by: Ran Benita <ran234@gmail.com>
types: store atoms instead of strings for level and type names

We don't use these strings much, so storing them in the manner they
were compiled saves some copying and space.

Signed-off-by: Ran Benita <ran234@gmail.com>
types: remove default type

The default type is copied over for each new key type to build on.
Further, it can be modified from within the xkb_types section itself,
with statements such as "type.modifiers = Lock" which affect all
subsequent type definitions.

The default type is (well, by default) just the simplest one level type
possible, with name "default". When no types are defined at all, it is
copied over to the keymap as the single type.

xkeyboard-config never changes the default type. There is also no sane
use case for doing so; changing any thing there doesn't make sense. So
instead of doing all the hard work of maintaining and copying this type,
which is practically never used, just remove it and initialize new types
appropriately.

Signed-off-by: Ran Benita <ran234@gmail.com>
Add API to query whether a modifier is consumed

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>