scanner-utils: add helper for appending an entire string

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

scanner-utils: add helper for hex string escape

Like the already existing oct.

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

Move benchmarks from tests to their own files in bench/

The tests only contain tests, and the benchmarks are more visible.

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

build: don't rebuild everything for libtest.la

We added a -fvisibilty=default to the libtest.la CFLAGS. When automake
sees that the CFLAGS are different from those of libxkbcommon.la, it
figures it should recompile all of the $(libxkbcommon_la_SOURCES),
instead of reusing the already-compiled object files.

But actually, the convenience library is not a shared object, it's just
used as an archive, thus the -fvisibility is entirely pointless. So
avoid the recompilations by just removing it.

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

scanner-utils: optimize str()/lit()

Replace the dog-slow unneeded strncasecmp() with an inlineable memcmp().

Before:
compiled 2500 keymaps in 8.348715629s

After:
compiled 2500 keymaps in 7.872640338s

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

keymap: rename XkbKeyGroupWidth to XkbKeyNumLevels

The "width" terminology comes from the group*width+level layout of the
keysyms in a key, as used in the old implementations. We don't keep all
the keysyms of a key in one array so change it to a more accurate name.

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

symbols: improve FindKeyForSymbol()

A bit more involved, but can short circuit.

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

symbols: use correct max value

xkb_level_index_t was initially uint16_t, now it's 32.

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

doc: disable alphabetical data structure index

It is useless - we have very little data structures.

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

doc: disable BRIEF_MEMBER_DESC

It's easier to quickly go through the functions in a module this way.
The names provide enough "brief description" to get someone to click for
the full description.

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

doc: disable tree view

It is redundant with the header navigation.

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

doc: linkify some references

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

x11, doc: add note about Key{Press,Release}->state field

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

x11, doc: add note about per-client flags like detectable autorepeat

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

keymap-dump: combine modifier_map's with the same modifier

A bit less efficient, but makes for shorter, nicer output.

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

rules: fix mlvo-not-used warning

An mlvo can also be used in an expansion, but we didn't mark them in
this case in commit d8a4f52cb95d989b4. This caused wrongful warnings on
something like -l ch -v fr -- the `fr` is only added via expansion.

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

quick-guide: fix xkb_state_key_get_syms() example

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

quick-guide: fix Java-esque array syntax

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

rules: warn when an RMLVO component isn't used

Due to wildcard matches in the rules file, this is only really useful
for misspelled or missing options, e.g.

$ ./test/rmlvo-to-kccgst -o comprose:ralt > /dev/null
xkbcommon: ERROR: Unrecognized RMLVO option "comprose:ralt" was ignored

Although it is more of a warning, it indicates a misconfiguration which
the user probably wants to see. Therefore the log level is ERROR.

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

parser: use "atom" instead of "sval" in yylval

"sval" is already used for "struct sval".

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

doc: reorder "Keymap Components" functions

Put the general keymap stuff before key-specific functions.

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

doc: move consumed modifier description to its own section

With small edits.

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

doc: order the modules better

Explicitly specify the files in INPUT so that "X11 Support" appears
after the main modules.

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

x11, doc: fix typo

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

x11, doc: add overview

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

test/keyseq: add test

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

configure.ac: add -Wdocumentation

It's supported by clang and warns about bad doxygen comments.

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

doc: fix @param display for xkb_x11_setup_xkb_extension()

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

symbols: use darray_foreach_from for nicer loop

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

Remove compatibility symbols

Remove the deprecated symbols that were used for ABI compatibility
during the transition period to the first stable version, 0.2.0.

The old *names* can still be used, programs which use the old names will
continue to work, as long as they were compiled against a stable
version (as they have been #defined to the new names from the start; see
xkbcommon/xkbcommon-compat.h). Namely, this will break binaries which:

1. Were compiled against a pre-stable version of libxkbcommon, and
2. Are linked against the next version of libxkbcommon, and
3. Expect to work.

This scenario is very unlikely, and will break in many other ways
anyway. Also, retaining support for these means including them in the
new symbol version file, which I would like to avoid.

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

build: use symbol versioning

Symbol versions provide a means by which ELF utilities can determine
whether a program is incompatible with a too-old library version so
that package management tools can autodetect version-based
dependencies and suggest upgrade paths.

[ran: swap xkbcommon.map and xkbcommon-x11.map]

Signed-off-by: Jan Engelhardt <jengelh@inai.de>
Signed-off-by: Ran Benita <ran234@gmail.com>

keycodes: fix keymap compilation with no aliases and malloc(0)==NULL

If the keymap doesn't have any key-aliases (which is certainly
possible), the calloc(num_key_aliases, ...) is allowed to return NULL
according to the C standard, but this is not an error.

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

ast-build: fix leak in error path

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

test: make most tests portable by copying linux/input.h locally

There is really no reason to deny these tests from different platforms
only for a few #defines.

The only linux-only test (or test program, it is not run by make check)
is interactive-evdev, which actually uses evdev.

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

Remove <linux/input.h> include from test/x11comp.c

libxkbcommon 0.4.3 introduces a new test, x11comp, which does not build
on non-Linux OSes because of the unconditional <linux/input.h> include.

This seems not needed even on Linux, so attached there is a simple patch
to remove it.

https://bugs.freedesktop.org/show_bug.cgi?id=83551

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

Merge pull request #11 from michaelforney/master

Fix typo in default-variant configure option

Fix typo in default-variant configure option

test/x11comp: don't hang if Xvfb is not available

If Xvfb is not present, posix_spawn still forks, but the child fails.
In that case, since we left the write fd of the pipe open in the parent,
we just kept waiting on the read() without noticing that the other side
is dead.

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

keymap: fix typo

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

keymap: fix description of xkb_keymap_key_get_syms_by_level()

The @level argument is restricted by xkb_keymap_num_levels_for_key(). Fix
the description to no longer mention xkb_keymap_num_layouts_for_key().

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

Bump version to 0.4.3

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

Update NEWS

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

test/state: add test_update_mask() test

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

state: make sure the mods are fully resolved after xkb_state_update_mask()

Virtual modifiers can have "mappings" to real modifiers, e.g. NumLock
may also set Mod2. In a normal turn of events, the various components
(depressed, latched, locked, and consequently effective) include the
mapped mods, because the masks are pre-resolved everywhere. However,
xkb_state_update_mask() accepts arbitrary mod masks, which may not be
resolved (if it comes from somewhere other than
xkb_state_serialize_mods()). So let's always resolve them ourselves.

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

Make the effective mod mask calculation available to other files

We will want to use that function in state.c as well.

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

state: no need for loop in xkb_state_update_mask()

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

test/x11comp: server writes \n to displayfd

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

test/x11-keyseq: new test

It is like test/stringcomp, only instead of using
xkb_keymap_new_from_string(), it uses xkbcomp to upload the keymap to a
dummy Xvfb X server and then xkb_x11_keymap_new_from_device().

If any of these components are not present or fails, the test is shown
as skipped.

The test is messy, fragile, limited and depends on external tools, but I
will improve on that later -- it's better to have a test.

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

x11/keymap: handle private actions

Previously we treated them as NoAction().

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

utils: add a STATIC_ASSERT macro

It'd be nicer to use C11's static_assert(), but it's easier to roll our
own C99 version using a trick I saw in xv6.

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

keymap: remove "flags" field of xkb_private_action

Private actions have no flags - only serialized data.

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

x11/keymap: be more defensive about the number of modifiers

There can be at most 16 vmods, and we rely on the facts that #vmods +
NUM_REAL_MODS (8) <= XKB_MAX_MODS (32) when accessing keymap->mods.mods.
But msb_pos() can potentially return up to #vmods = 32 if the server is
malicious, so we need to truncate it.

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

x11/keymap: don't forget to add the vmod offset in get_vmods

The first 8 modifiers in keymap->mods are the real modifiers; the virtual
 modifiers are then at slots 8-24. But XkbGetMap's virtualMods mask
starts the virtual modifiers at zero, so we need to add an offset (like
we do correctly in get_vmod_names()).

https://github.com/xkbcommon/libxkbcommon/issues/9

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

docs: move keysym-transformations page to a better position

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

docs: fix self-reference

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

interactive-evdev: don't use sysexits.h

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

ast-build: make sure InterpDef is freeable

With the following two rules:

    InterpretDecl   :       INTERPRET InterpretMatch OBRACE
                                VarDeclList
                            CBRACE SEMI
                            { $2->def = $4; $$ = $2; }
                    ;

    InterpretMatch  :       KeySym PLUS Expr
                            { $$ = InterpCreate($1, $3); }
                    |       KeySym
                            { $$ = InterpCreate($1, NULL); }
                    ;

And the fact that InterpCreate doesn't initialize ->def, if the
VarDeclList fails, the %destructor tries to recursively free the
uninitialized ->def VarDef. So always initialize it.

That was the only problematic code in the parser for %destructor (I'm
pretty sure).

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

parser: silence bison "unused value" warnings

Previous commit triggered these for some reason:

/home/ran/src/libxkbcommon/src/xkbcomp/parser.y:555.25-33: warning: unused value: $1 [-Wother]
 CoordList       :       CoordList COMMA Coord
                         ^^^^^^^^^

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

parser: don't leak AST nodes for discarded symbols

If the parser has symbols on the stack, and then enters an error, it
discards the symbols and fails. But their actions which allocate AST
nodes had already ran. So we must free these to avoid leaks.

We use %destructor declarations, see
http://www.gnu.org/software/bison/manual/html_node/Destructor-Decl.html

Note: byacc only supports %destructor when compiled with
--enable-btyacc. Also, it doesn't support using the parse-param in the
destructor. So we might revert this commit before the next release, or
forget about byacc.

https://github.com/xkbcommon/libxkbcommon/issues/8

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

test: add file with a syntax error

We didn't really have any. It also a exposes a memory leak, since the
parser doesn't clean up the AST nodes of the discarded symbols.

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

Replace darray_mem with a new darray_steal

That's a more declarative interface.

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

ast-build: use cast instead of ->common

Missed in 1b2bb204e0baa2246a6232aea762c1edb00cd44a.

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

types: refactor CopyKeyTypesToKeymap

So it's OOM-safe and doesn't clobber keymap on failure.

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

keycodes: split CopyKeyInfoToKeymap to several functions

It's a bit easier to read and self-documenting. Also handles OOM better.

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

parser: don't shadow "str"

It's a name of a function in scanner-utils.h and also of some
parameters.

https://bugs.freedesktop.org/show_bug.cgi?id=79898

Reported-by: Bryce Harrington <b.harrington@samsung.com>
Signed-off-by: Ran Benita <ran234@gmail.com>

x11: don't iterate on empty batches

If count % SIZE == 0 we did a useless iteration where start==stop. It's
harmless but strange, so don't do that.

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

Remove unnecessary !!(expressions)

_Bool already does that.

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

rules: fix leak on failure

matcher_match() builds up the kccgst's, and we steal the memory on
success. But on error we didn't free it.

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

Bump version to 0.4.2

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

Update NEWS

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

x11: fix out-of-bounds access in adopt_atoms() error handling

Two problems:

- `j` can be >= `SIZE`, and needs to be wrapped like in the rest of the
   code.

- `cookies[j % SIZE]` is not initialized if there's no atom in `from[j]`.

The is manifested when:

- We've already gone through one batch (>= 128 atoms) (in fact this
  cannot happen in call to `adopt_atoms` in the current code).

- An XCB request failed in the middle of a batch.

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

ast-build: don't leak on OOM in BoolVarCreate

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

parser: show the keysym in "unrecognized keysym" messages

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

doc: fix new doxygen version warnings

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

keycodes: fix uninitialized variable

Happened in one of the previous commits. For some reason, gcc doesn't
warn about this, but clang does...

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

xkbcomp: don't align enum values

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

xkbcomp: use straight assignment instead of CopyModSet

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

keymap, keycodes, compat: don't use darray for LEDs

Use a static array of size XKB_MAX_LEDS instead, as in xkb_mod_set.

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

keymap: don't use darray in xkb_mod_set

Instead just statically allocate the mods array (of size MAX_MOD_SIZE =
32). The limit is not going anywhere, and static allocations are nicer
(nicer code, no OOM, etc.). It's also small and dense enough.

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

keymap: add and use xkb_mods_{foreach,enumerate}()

To iterate over an xkb_mod_set. Slightly nicer interface and makes
transitioning from darray easier.

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

keymap: rename xkb_foreach_key to xkb_keys_foreach

We'll use the format xkb_foos_foreach and xkb_foos_enumerate for the
various iterators.

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

keymap: protect xkb_foreach_key macro params

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

darray: remove unused darray_foreach_reverse()

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

utils: detect overflow in memdup()

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

symbols: use xkb_mod_set instead of entire keymap

The keymap is not removed entirely from the Info (just constified),
since it is still needed in AddKeySymbols() for looking up aliases. This
dependency will be removed in the future.

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

types: use xkb_mod_set instead of entire keymap

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

compat: use xkb_mod_set instead of entire keymap

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

vmod: take xkb_mod_set instead of the entire keymap

This is the only place where the modifier information is modified. We
will make it local to a given XKB file (after which it will be merged
into the keymap). Currently it changes the keymap directly, which
sidesteps the abstraction and leaves side-effects even if the XkbFile's
compilation fails.

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

action: take xkb_mod_set instead of the entire keymap

A couple of modiifer actions need this information, but not the entire
keymap.

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

expr: take xkb_mod_set instead of the entire keymap

The modifier-resolving functions only need the modifier information.

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

text: take xkb_mod_set instead of the entire keymap

The modifier printing functions only need the modifier information, they
don't care about keys or leds, etc.

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

Add struct xkb_mod_set

The only thing that the compilation phase needs the keymap for currently
is for access to the modifier information (it also modifies it in
place!). We want to only pass along the neccessary information, to make
it more tractable and testable, so instead of passing the entire keymap
we add a new 'mod_set' object and pass a (const) reference to that.
The new object is just the old array of 'struct xkb_mod'.

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

keymap: rename wrap_group_into_range -> XkbWrapGroupIntoRange

It better fits with the naming convention in keymap.h.

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

keymap: move ModNameToIndex from text.c and use it in keymap.c

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

symbols: separate ctx

Same as was done for compat and types.

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

compat: separate ctx

Same as was done for types.

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

types: separate ctx

Separate the ctx object to its own field in CompatInfo, instead of doing
keymap->ctx.

The compilation functions should not have direct access to the keymap;
instead they should process the files with their own independent state
(in the *Info structs) as much as possible, and only at the end should
they be copied (i.e. commited) to the keymap. If the compilation fails,
it leaves no by-products. It's also just good form.

This was seemingly the original author's intention, but I suppose he cut
a few corners (mostly with the handling of virtual modifiers, which are
threaded through types -> compat -> symbols).

This commit is the first step and may look artificial; however the
'keymap' field will be removed shortly.

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

action: convert a few missed unsigned -> enum xkb_action_type

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

expr: fix handling of unknown integer binary operator

We can't reach the default branch but at least make it do something
sensible.

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

doc: explain keysym/string transformation

The documentation should be clear about what is happening, even if it's
rather unlikely anyone will really dig into the details.

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