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>

doc: add @since annotations for API added since 0.3.0

And also add release dates to the NEWS.

We're adding API freely, so this can make life easier for anyone who
wants to stay compatible with an older version.

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

Add .travis.yml file

This CI service https://travis-ci.org/ builds the project in several
configurations, runs the tests, and if something fails it sends an email.
Testing on some other systems is always good, and there don't seem to
be any drawbacks to this, so why not.

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

configure.ac: fix enable_x11 handling

Explicitly passing --enable-x11=yes would actually disable it.

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

Bump version to 0.4.1

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

Update NEWS

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

build: trim down generated doxygen docs

Remove the huge verbatim copies of the header files.

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

build: add docs to EXTRA_DIST

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

state: fix consumed modifier calculation

The current calculation is in short:
    entry ? (entry->mask & ~entry->preserve) : 0

This changes it be
    type->mask & ~(entry ? entry->preserve : 0)

This is what Xlib does. While less intuitive, it is actually more
correct, if you follow this deduction:

- The key group's type->mask defines which modifiers the key even cares
  about. The others are completely irrelevant (and in fact they are
  masked out from all sided in the level calculation). Example: NumLock
  for an alphabetic key.

- The type->mask, the mods which are not masked out, are *all* relevant
  (and in fact in the level calculation they must match *exactly* to the
  state). These mods affect which level is chosen for the key, whether
  they are active or not.

- Because the type->mask mods are all relevant, they must be considered
  as consumed by the calculation *even if they are not active*.

Therefore we use type->mask instead of entry->mask.

The second change is what happens when no entry is found: return 0 or
just take preserve to be 0? Let's consider an example, the basic type

    type "ALPHABETIC" {
        modifiers = Shift+Lock;
        map[Shift] = Level2;
        map[Lock] = Level2;
        level_name[Level1] = "Base";
        level_name[Level2] = "Caps";
    };

Suppose Shift+Lock is active - it doesn't match any entry, thus it gets
to level 0. The first interpretation would take them both to be
unconsumed, the second (new one) would take them both to be consumed.
This seems much better: Caps is active, and Shift disables it, they both
do something.

This change also fixes a pretty lousy bug (since 0.3.2), where Shift
appears to apparently *not* disable Caps. What actually happens is that
Caps is not consumed (see above) but active, thus the implicit
capitalization in get_one_sym() kicks in and capitalizes it anyway.

Reported-by: Davinder Pal Singh Bhamra
Signed-off-by: Ran Benita <ran234@gmail.com>

Reformat README markdown

So that github displays it as markdown, and correctly.

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

doc: add a quick guide to the library

This is a nice intro to the documentation, and also preferably gently
pushes users to the "proper way" of using the library, which can be
confusing.

See also: http://fooishbar.org/tell-me-about/xkbcommon-intro/

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

state: apply control transformation on utf8/utf32 keysym strings

This is required by the specification:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Control_Modifier
and clients expect this to happen.

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

Reported-by: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>

state: add xkb_state_key_get_{utf8,utf32}() API functions

These functions generally have the same effect as
xkb_state_key_get_syms() + xkb_keysym_to_utf{8,32}().

So why add them?

- They provide a slightly nicer interface, especially if the string is
  the only interest.

- It makes the handling of multiple-keysyms-to-utf8 transparent. For the
  designated use-case of multiple-keysyms (unicode combining
  characters), this is a must. We also validate the UTF-8, which the
  user might not otherwise do.

- We will need to apply some transformation on the resulting string
  which depend on the xkb_state. This is not possible with the
  xkb_keysym_* functions.

With these functions, the existing xkb_keysym_to_utf{8,32}() are not
expected to be used by a typical user; they are "raw" functions.

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

Add utf8.{c,h} for common UTF-8 util functions

We need to validate some UTF-8, so this adds an is_valid_utf8()
function, which is probably pretty slow but should work correctly.

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

configure.ac: fix message when X11 support is disabled

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

x11: relax XkbGetNames requirements

It is valid for a keymap to not have key aliases, group names and
various other things. But the current test requires all of them to be
present in the reply, which causes us the fail on such keymaps (as the
XQuartz one).

Instead, require only what we really need. The virtual-mods names may
not be strictly required, but it seems safer to leave it in for now.

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

Reported-by: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>

doc: extend xkb_rule_names default-value description

Especially a mention of the XKB_DEFAULT_* envvars was missing.

Reported-by: Paeglis Gatis <Gatis.Paeglis@digia.com> (thanks!)
Signed-off-by: Ran Benita <ran234@gmail.com>

doc: remove possibly confusing comment

There are valid reasons to use the other keymap-creation functions, if
one needs them. On the other hand, if one is supposed to use RMLVO, it
is more or less the only choice, so the comment is not needed in this
case as well.

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

interactive-x11: beef up select_events a bit

- Specify in detail which parts of the events we care about. In theory
  the X server should not bother us with things we didn't ask for. In
  practice it still does, but oh well.

- Use the _aux version of select_events. This is the correct one to use,
  the non-aux version is useless.

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

doc: add comments about update_key() and get_syms() order

I remember we had a comment about this, but I can't find it. So add it
again.

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

symbols, keycodes: fix int return type when bool is intended

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

symbols: cleanup SetSymbolsField

Normalize the style and error message levels.

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

symbols: fix possible use of uninitialized value

Nothing bad can come out of it, but for some reason this error didn't
return early (inherited from xkbcomp).
Also promote the log message to an error, as it clearly is.

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

state: Add xkb_state_key_get_consumed_mods

This retrieves the mask of consumed modifiers for a given key and state,
which is helpful for toolkits without having them to do it one modifier
at a time, or pass in 0xFFFFFFFF to xkb_state_remove_consumed_mods to
"reverse-engineer" the consumed mods.

action: unify SetLatch and Lock handler functions

This is a little shorter and follows easier from the spec flag
description table.
Also a few were too permissive (like allowing LatchToLock in SetMods).

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

action: add a common CheckBooleanFlag function

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

keymap: change action flag NO_ACCEL -> ACCEL

It's easier to deal with, but we need to set it as "factory default".

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

action: fix SwitchScreen "same" field handling

This used to *unset* a flag called "SwitchApplication"; we changed the
flag to "same" but forgot to switch the cases.

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

keymap-dump: add missing support for NoLock and NoUnlock flags

Based on a libxkbfile patch by Andreas Wettstein.

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

keymap-dump: don't print "affect=lock" in PtrLock

It's the same as no flags, so might as well not print it.
(In fact it is slightly harmful, because it actively *clears* the affect
flags, which might have been set in some other manner. But in practice
this cannot happen).

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