keymap-dump: use ActionTypeText

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

keymap-dump: use SITextMatch

text.c has the exact same function.

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

keymap-dump: clean up write_buf function

It would have been nice to use open_memstream here if it was portable
enough (maybe someday it will?).

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

Add an interactive evdev test

The program reads key events from evdev input devices, puts them through
the library and prints some information about them. It's nice for
experimenting, quick testing and trying to break it with random stuff
(already found some!).

It is called "interactive" for lack of a better name. It's a bit
hackish, but can easily be extended, made more portable etc, in the
future.

Signed-off-by: Ran Benita <ran234@gmail.com>
Conflicts:
Makefile.am
test/.gitignore

Remove ExprResult

Convert the IdentLookup typedef away from ExprResult, which drags along
everything else. This should also make all of the conversions explicit.

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

expr: remove support for evaluating string as integer

As the comment nicely puts it, this is a bit weird. When you try to
evaluate an expression of type string into an integer, what it does is:
    "" -> 0
    "c" -> (ascii value, i.e. like a char literal)
    more than one char -> error
The first one is obviously not very useful; why not just write 0?
The second one might be useful (though I don't see where in a keymap
it would be), but I don't think anyone would consider trying "X" for
that anyway.

A look through xkeyboard-config shows "" only used once as a string, and
"X" also only used as strings (and mostly in geometry which we don't
evaluate anyway). And I seriously doubt it's used (purposely) anywhere
else. So remove it.

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

Don't create contexts with no include paths

Clean up the return code handling from
xkb_context_add_include_paths_default, and thus fail context creation if
we can't add any of the default include paths, but were asked to.  If
this happens, dump the DFLT_XKB_CONFIG_ROOT out in the log message, so
at least we know what we aren't looking at.

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

context test: Use test_get_context()

So we don't die if we haven't got a valid global include path.

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

expr: drop ExprResult from ResolveEnum

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

expr: drop ExprResult from ResolveMask

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

expr: drop ExprResult from ResolveInteger

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

expr: drop ExprResult from ResolveButton

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

expr: drop ExprResult from ResolveLevel

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

expr: drop ExprResult from ResolveKeyCode

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

expr: drop ExprResult from ResolveGroup

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

expr: drop ExprResult from ResolveKeysym

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

expr: drop ExprResult from ResolveBoolean

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

expr: drop ExprResult from ResolveString

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

expr: drop ExprResult from ResolveLhs

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

expr: drop ExprResult from ResolveKeyName

Explicit is better than implicit, and this union makes it hard to follow
what's what, particularly the confusion with ival/uval.
The other Resolve functions will follow.

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

parser: untabify

Run vim's :%retab and some resulting indention fixes.

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

Convert defines to enums in xkbcomp.h

For statement / expression types.

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

Fix incorrect comparison

ExprFieldRef goes into the ExprDef op field, not the type field.

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

utils: add/replace string equality macros

It's more tidy and less error prone, since we use strcasecmp == 0 a lot.
We replace strcmp == 0 by streq, strcasecmp == 0 by istreq,
uStrCasePrefix by istreq_prefix and uDupString by strdup_safe.

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

Drop Xkbc prefix of text functions

Not really needed and inconsistent.

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

Use xkb_mod_mask_t and xkb_mask_index_t throughout

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

Remove alloc.{c,h}

These functions are more appropriate elsewhere now.

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

scanner: don't strdup key names

The key name is always XkbKeyNameLength (= 4) bytes, so we can maintain
it directly in YYSTYPE union and copy when needed, instead of treating
it like a full blown string and then copy. This means the scanner
checks the length itself.

rulescomp under valgrind, before:
==1038==   total heap usage: 168,403 allocs, 168,403 frees, 9,732,648 bytes allocated
after:
==9377==   total heap usage: 155,643 allocs, 155,643 frees, 9,672,788 bytes allocated

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

Some atom related optimizations

We often get a strdup'd string, just to pass it over the atom_intern and
then immediately free it. But atom_intern then strdup's it again (if
it's not interned already); so instead we can have the interning "steal"
the memory instead of allocing a new one and freeing the old one. This
is done by a new xkb_atom_steal function.

It also turns out, that every time we strdup an atom, we don't actually
modify it afterwards. Since we are guaranteed that the atom table will
live as long as the context, we can just use xkb_atom_text instead. This
removes a some more dynamic allocations.

For this change we had to remove the ability to append two strings, e.g.
    "foo" + "bar" -> "foobar"
which is only possible with string literals. This is unused and quite
useless for our purposes.

xkb_atom_strdup is left unused, as it may still be useful.

Running rulescomp in valgrind, Before:
==7907== total heap usage: 173,698 allocs, 173,698 frees, 9,775,973 bytes allocated
After:
==6348== total heap usage: 168,403 allocs, 168,403 frees, 9,732,648 bytes allocated

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

expr: don't divide by zero

Calculator parser 101.

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

types: fix canonical types copying

Without the re-initialization, the copying fails. This wasn't noticed
because this code practically never gets executed with ordinary keymaps.

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

keycodes: fix valgrind warnings

==7071== Conditional jump or move depends on uninitialised value(s)
==7071==    at 0x40B6CB: AddIndicatorName (keycodes.c:148)
==7071==    by 0x40C34F: MergeIncludedKeycodes (keycodes.c:420)
==7071==    by 0x40C613: HandleIncludeKeycodes (keycodes.c:480)
==7071==    by 0x40D022: HandleKeycodesFile (keycodes.c:733)
==7071==    by 0x40D79F: CompileKeycodes (keycodes.c:881)
==7071==    by 0x401E22: compile_keymap (xkbcomp.c:157)
==7071==    by 0x402091: xkb_map_new_from_kccgst (xkbcomp.c:229)
==7071==    by 0x40216A: xkb_map_new_from_names (xkbcomp.c:254)
==7071==    by 0x4046F5: test_compile_rules (common.c:164)
==7071==    by 0x4015C1: test_rmlvo (rulescomp.c:44)
==7071==    by 0x40180D: main (rulescomp.c:98)

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

parse: remove unused #define

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

expr: Remove ExprResolveFloat

Remnant from geometry.

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

makekeys: Add top_srcdir to include path

Fixes distcheck with no /usr/include/xkbcommon.

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

Add test for logging functionality

Just to make sure everything works properly.

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

Remove old logging leftovers

Everything has been converted.

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

xkbcomp: use new log functions

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

parse: use new log functions

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

path: use new log functions

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

misc: use new log functions

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

vmod: use new log functions

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

rules: use new log functions

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

expr: use new log functions

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

action: use new log functions

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

types: use new log functions

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

types: add keymap to KeyTypesInfo

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

compat: use new log functions

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

compat: add keymap to CompatInfo

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

symbols: use new log functions

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

symbols: add keymap to SymbolsInfo

and use it. Also make sure info is the first argument to the functions
in this file.

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

keycodes: use new log functions

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

keycodes: add keymap to KeyNamesInfo

and let the info always be the first argument to the various functions,
just for consistency (and it acting as the contex for this file).

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

Add logging API

Add new public API to provide the library users with some options to
control and customize the logging output from the library. It is based
upon the skeleton from the libabc demo libray:
https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git
which is public domain and works pretty well.

This requires passing in the context object in every logging call, and
thus the conversion is done file by file. We also remove the global
warningLevel variable in favor of a verbosity level in the context,
which can be set by the user and is silent by default.

One issue is the ACTION calls, which, while nice, do not play very well
with line- and priority-based logging, and would require some
line continuation handling or keeping state or some other compromise. So
instead remove these and just inline them with their respective
warning/error. So instead of:
    ERROR("Memory allocation failed\n")
    ACTION("Removing all files on hardisk\n")
its something like that:
    log_err("Memory allocation failed; Removing all files on harddisk\n")

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

utils: replace FATAL by malloc_or_die

"Out of memory" is enough in this case. If we want to be OOM-safe this
makes it clear where to begin.

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

utils: remove Xfuncproto.h and use our own macros

Add XKB_EXPORT to replace _X_EXPORT, and copy the definitions of
_X_ATTRIBUTE_FOO as ATTR_FOO.

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

utils: remove uTypedAlloc/Calloc

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

build: drop the include/ directory

The include/ dir is somewhat redundant and makes it just a bit harder to
handle the -I directives from out side of automake; without it the
default $(top_buildir) just works.
Here's also some further justifications I found:
http://smcv.pseudorandom.co.uk/2008/09/pc-uninstalled/

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

Fix bison 2.6 and clang warnings

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

Remove CommonInfo

Not used by anything anymore.

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

types: use list instead of CommonInfo for KeyTypeInfo

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

Simplify HandleInclude functions

Instead of special casing the first include, process it inside the loop
as well. It works perfectly fine.

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

Remove haveSelf include feature

When including a file from another file, its possible to do something
like this:
    include "+some(other)+files"
with the "+" or "|" in the beginning. What will happen then is that
instead of processing the include files separately and then merging into
the existing info, we instead start with the existing info and merge
into it as we go, as if it was written explicitly before the first "+".

It's not particulary clear what this may be useful for. Since it's not
used by xkeyboard-config, not documented anywhere (and google doesn't
bring up anything), completely untested and kind of ugly, remove this
"feature". It most likely never been used.

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

types: use list instead of CommonInfo in PreserveInfo

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

types: move global static tok_ atoms into KeyTypesInfo

The atoms are context-dependent.

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

compat: use list instead of CommonInfo in LEDInfo

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

Use xkb_group_index_t for group variables throughout

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

Remove _X_EXPORT from xkb_key_get_group/level

We should add them to xkbcommon.h if they need to.

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

compat: use list instead of CommonInfo in SymInterpInfo

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

Move indicators.c code into compat.c

It is only used there. Allows some refactoring.

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

Convert macros to inline functions

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

keycodes: use list instead of CommonInfo in IndicatorNameInfo

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

keycodes: use list instead of CommonInfo in AliasInfo

Always pass around the KeyNamesInfo which contains the list head.

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

Move alias.c functions into keycodes.c

They are only used in this file.

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

symbols: don't use CommonInfo in KeyInfo

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

symbols: use list for ModMapEntry's

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

Add common linked list implementation

Taken from xserver/include/list.h. The changes made are:
* Drop the xorg_ prefix and some typedef from the end.
* Rename _for_each_entry macros to just _foreach (like darray).
* Rename list_is_empty to list_empty (like darray).
* Add a list_replace function which we use later.

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

symbols: remove alias info

It's never used - all of the aliases are added in the keycodes section.

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

Pass around xkb_key's instead of keycodes

This way we don't need to look up the key every time. We now only deal
with keycodes in the public API and in keycodes.c.

Also adds an xkb_foreach_key macro, which is used a lot.

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

map: verifiy that the keycode is legal

In case someone passes in a bad keycode.

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

Remove redundant keymap->keys resizes

The size (i.e. max_keycode) is determined in the keycodes section, which
gets compiled first.

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

Remove GroupsWidth macro

Use key->width directly instead.

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

Remove unused 'groupInfo' in KeyTypeInfo

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

Get rid of group_info

This is 8 bits which hold how many groups the key has, what to do the
key group is out of bound and the group to redirect to if want to. This
may save a few bytes, but is really annoying. So instead, just lay out
the fields separately. We can optimize later in a sane way, with pahole,
bitfields, etc. if we want.

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

Get rid of struct xkb_sym_map

Past its usefulness; put the stuff directly in xkb_key.

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

Get rid of struct xkb_key_name

Just embed it directly.

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

Add common xkb_key struct

Instead of having a million arrays from the keycode to various
key-specific info in the keymap, add a single struct xkb_key to hold all
of the data for the key in one object. This way we can pass it around,
do some refactoring and make the code simpler. It's also nice to see
everything in one place.

The keys array is still indexed by keycode, which is suboptimal because
there may be a lot of holes (i.e. unused keycodes between min_key_code
and max_key_code). By the end of this series it would be abstracted
enough to replace it by a hash table or similar if there's ever a need.

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

Replace KeyInfo 'key' variable name by 'keyi'

We want to reserve the name 'key' for something else.

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

Replace xkb_keycode_t 'key' variable name by 'kc'

We want to reserve the name 'key' for something else.

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

Convert indecipherable macros to inline functions

This was fun.

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

symbols: split initialization code from CompileSymbols

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

Move per_key_repeats and enabled_ctrls to keymap

All of the per-key data and global flags are now visible directly in the
keymap.

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

Get rid of xkb_key_names

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

Get rid of xkb_indicator

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

Get rid of xkb_compat_map

Same as xkb_{client,server}_map which were already removed.

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

Get rid of xkb_server_map

Same as xkb_client_map which was removed before.

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

Get rid of xkb_client_map

We don't make this distinction anymore, and the separate allocations
just make it harder to reason about. Since we require that all of
symbols, types, compat etc. be present, we should just put stuff
directly in the keymap struct.

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

Run source tree through uncrustify

.uncrustify.cfg committed for future reference also, but had to manually
fix up a few things: it really likes justifying struct initialisers.

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

Fix typo in out of range group calculation

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

Remove unused control num_groups

We have xkb_map_num_groups for that.

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