Add xkbcommon-compat.h and compat.c

So we can start renaming stuff while retaining backwards source and
binary compatibility.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Add _xkbcommon_ prefix to parser and lexer symbols

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
API change: Rename xkb_map_* and group -> layout

Move xkb_map_* functions to xkb_keymap_*, xkb_key_* functions under
either xkb_keymap or xkb_state, and rename groups to layout in all
user-visible API.

Backwards-compatible hooks are provided, such that old source will
build, but silently mangled to the new names, and old binaries will
also continue to work.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Promote keymap enumeration API to public

Rename the functions to get keysyms by key/layout/level to fit with the
recent public API renames, and expose them.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
fixup! Promote keymap enumeration API to public

Signed-off-by: Ran Benita <ran234@gmail.com>
Don't use xkbcommon-compat names in internal code

Signed-off-by: Ran Benita <ran234@gmail.com>
Rename private xkb_map_new to xkb_keymap_new

To be consistent with the API rename.

Signed-off-by: Ran Benita <ran234@gmail.com>
Move xkb_state functions from map.c to state.c

Seems more appropriate.
Only change is to turn some xkb_state_get_map functions to direct
state->keymap.

Signed-off-by: Ran Benita <ran234@gmail.com>
state, map: check XkbKey != NULL where missing

Signed-off-by: Ran Benita <ran234@gmail.com>
Rename map.{c,h} to keymap.{c,h}

Seeing as we don't like "map" anymore.

Signed-off-by: Ran Benita <ran234@gmail.com>
Don't choke on RMLVO layout string with holes

This old rules parser gives the same kccgst here, so in the interest of
staying compatible we shouldn't fix it there. Similarly we shouldn't
touch ParseIncludeMap, so this is the best place to handle this.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: avoid reverse iteration in PrepareKeyDef

No need for that.

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

What this code does is, in case someone compile a keymap like -layout
'us,us,us' then only one group would be created. If there is anything
which differentiates between any of the groups (e.g. a variant, another
layout), then this is not done.
This is pretty obscure, only saves a few kbytes in the final keymap, and
if the user asked for it, why not let her?

Signed-off-by: Ran Benita <ran234@gmail.com>
state: special case effective group in layout_is_active

Currently, xkb_state_layout_{index,name}_is_active may report multiple
groups as effective, because at looks at base,latched,locked separately.
But there can only be one effective group, which is computed from the
other three. So if XKB_STATE_EFFECTIVE is requested, just compare to the
effective group we have computed.

We also modify mod_{index,name}_is_active similarly, just for symmetry
(there the effective mask is just an OR of the other three so the
current test is correct).

Signed-off-by: Ran Benita <ran234@gmail.com>
state: separate group wrapping/clamping to a function

We'll need this function for wrapping our global effective group as
well.

Signed-off-by: Ran Benita <ran234@gmail.com>
state: correctly wrap state->locked_group and ->group

These values weren't wrapped before, which caused group_index_is_active
to stop working after a few group switches.

Also, the current group-wrapping function didn't take into consideration
actions such as LockGroup=-1, which need to wrap around, etc.
xkb_layout_index_t is unsigned, but it was used to hold possibly
negative values (e.g. locked_group is 0 and gets a -1 action).

This group wrapping function should now act like the XkbAdjustGroup
function from xserver, and at least ./test/interactive doesn't bring up
any problems with group switching any more.

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