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>
configure.ac: fix bug report url

Signed-off-by: Ran Benita <ran234@gmail.com>
configure.ac: remove XORG_CHECK_MALLOC_ZERO

We don't use its result.

Signed-off-by: Ran Benita <ran234@gmail.com>
configure.ac: add XORG_MEMORY_CHECK_FLAGS

Adds some memory checking (e.g. MALLOC_PERTURB_) to tests.

Signed-off-by: Ran Benita <ran234@gmail.com>
configure.ac: use XORG_TESTSET_CFLAG for -fvisibility=hidden

Probably shouldn't use CFLAGS for that but o well.

Signed-off-by: Ran Benita <ran234@gmail.com>
state: missing XKB_EXPORT on xkb_state_key_get_level

And some error handling.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: fold PrepareKeyDef into CopySymbolsDef

The function is big enough already but it's nicer to read sequentially.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: disallow changing global defaults from within a key statement

Pretty much like e5fdbcbb9943e9fe, again it isn't used.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: fix memleak from default KeyInfo

If the default KeyInfo gets any keysyms or actions, it needs to be
free'd.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: convert KeyInfo->groups to darray

Before it was a static array of size XKB_NUM_GROUPS.

The previous cleanups made this transition a bit easier. This is a
first step for removing the XKB_NUM_GROUPS hardcoded limit; but for now
we still check that the groups are < XKB_NUM_GROUPS (e.g. in
ResolveGroup and GetGroupIndex) until the keymap, etc. is worked out as
well.

This also makes us alloc quite a bit less (this is just rulescomp):
Before:
==51999==   total heap usage: 291,474 allocs, 291,474 frees, 21,458,334 bytes allocated
After:
==31394==   total heap usage: 293,595 allocs, 293,595 frees, 18,150,110 bytes allocated
This is because most rmlvo's don't use the full 4 layouts that KeyInfo
had always alloced statically before.

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