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>

keymap-dump: unbreak some complex lines

It's very hard to read as-is. Apologies for those reading over a VT100.

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

expr: simplify ExprResolveButton

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

action: don't pass a keymap where a ctx is sufficient

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

action: add missing array_ndx checks

Only the "data" field can have them, and every other field needs to
error out if it appears. But some didn't check.

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

action: move array_ndx errors into the Check functions

Makes more sense and flows more nicely this way.

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

action: fix missing support for "affect" field

Support for setting this field was missing from the LockMods and
LockControls actions.

Based on a xkbcomp patch by Andreas Wettstein.

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

ast: cast to ParseCommon explictly instead of using ->common

Some tools were getting mighty confused with what we were doing.

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

action: simplify Check* functions

Instead of using those t1 t2 variables, pass the final destinations
directly (while making sure they are not modified in case of error).

This also ensures the types are right, e.g. in CheckGroupField it should
be int32_t, not xkb_layout_index_t (and indeed it takes a negation!).

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

darray: fix indentation

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

vmod: bring back support for direct vmod -> real mod mapping

This brings back the functionality that was removed in
b9c87eb710ba4a86455601ca8c5a516b25e20366. Though it is not used in
xkeyboard-config, from our current perspective it can be quite useful to
be able to set the mappings directly, thus sidestepping the ugly and
legacy-ridden modifier_map statement.

Here's an example of how to get rid of modifier_map statements (though
that would break core-X11 applications, since they must have the
mappings through keysyms):
    virtual_modifiers NumLock = Mod2;
    virtual_modifiers Alt = Mod1;
    // Would be nice to map these to Alt, but that would be
    // incompatible with xkbcomp and somewhat complicated
    virtual_modifiers LAlt = Mod1;
    virtual_modifiers RAlt = Mod1;
    virtual_modifiers LevelThree = Mod5;
    virtual_modifiers RControl = Control;
    virtual_modifiers LControl = Control;
    virtual_modifiers Super = Mod4;
    virtual_modifiers Meta = Mod1;
    virtual_modifiers Hyper = Mod4;
    virtual_modifiers AltGr = Mod5;
    virtual_modifiers LShift = Shift;
    virtual_modifiers RShift = Shift;

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

build: small fixes and formatting of Makefile.am

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

build: fix libtest AM_CLFLAGS typo

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

Move src/xkbcomp/scanner-utils.h to src/

As we'll use it for things unrelated to xkbcomp.

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

build: fix configure test for yacc

It only works if 'bison' or 'byacc' are provided, but sometimes byacc
is installed as plain 'yacc'. The check fails for that.

I broke this in bdd8c11, restore Daniel's retrospectively clever check.

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

scanner: sort out scanner logging functions

First, make the rules and xkb scanners/parsers use the same logging
functions instead of rolling their own.

Second, use the gcc ##__VA_ARGS extension instead of dealing with C99
stupidity. I hope all relevant compilers support it.

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

rules: always %-expand kccgst values

Previously the early-exit codepath might have left some values
unexpanded, and we'd go looking for e.g "%l%(v)".

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

test/rmlvo-to-kccgst: use default RMLVO values in translation

The tool's supposed to display exactly the same results as the library
code.

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

context: add xkb_context_sanitize_rule_names()

We want all the default logic in a test, so encapsulate it in this
function, and make all the get_default_* functions static.

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

rules: print full path in error messages

There can be multiple include paths. But it's nicer in any case.
This also makes scanner_error actually use log_err instead of log_warn -
oops.

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

rules: include the path in failed-to-map error message

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

context: fix wrong VARIANT instead of LAYOUT getenv

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

ast: remove unneeded 'ctx' param to XkbFileCreate

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

x11: don't trust keycode before testing its range

The assert is not very useful access the key just before.

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

keymap: reduce padding in struct xkb_sym_interpret

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

symbols: steal keys and modmaps when merging if possible

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

compat: steal interps and leds when merging if possible

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

types: steal types when merging if possible

Like we do everywhere else. Removes some unnecessary allocations and
copying.

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

doc: move some file comments into txt files in doc/

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

state: check wrap_group_into_range() return value

It returns XKB_LAYOUT_INVALID in case num_groups == 0. So we shouldn't
just save it in the state.
Note, though, that this condition is generally impossible.

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

x11: add 0 < ctrls->numGroups <= 4 assertion

This only happens if something is wrong in the server; a valid keymap
cannot be had in any case.

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

Remove m4/.gitkeep

Now there's a file in there.

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

keysym: use safe keysym comparison function

Instead of thinking about signed <-> unsigned an whatnot.
bsearch() is inline in glibc, so gcc optimizes this away anyway.

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

scanner: make line and column unsigned

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

rules: get rid of struct location

Use the scanner token_{line,column} like we do in the other places.

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

api: deprecate XKB_MAP_COMPILE_PLACEHOLDER, and use KEYMAP instead of MAP

The PLACEHOLDER was not meant to be used, but c++ doesn't like passing 0
to enums, so it was used. For this reason we add all the NO_FLAGS items,
so the PLACEHOLDER shouldn't be used anymore.

Second, XKB_MAP is the prefix we used ages ago, KEYMAP is the expected
prefix here. So deprecate that as well.

The old names may still be used through the xkbcommon-compat.h header,
which is included by default (no need to include directly).

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

x11: make sure not to use compat header

src/keymap.h already defines the necessary header guard, so just reverse
the include order.

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

x11: make some #defines unsigned

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

x11: fix truncation of xkb controls mask off the wire

It's uint32_t, not uint16_t, so we were losing flags (not that it
matters in this case).

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

x11: make msb_pos return unsigned

It was initially returning -1 for all-zero arguments, but now it returns
0.

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

keysym: fix types in bin_search

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

state: optimize xkb_state_led_update_all()

Before:
    ran@ran:~/src/libxkbcommon$ ./test/bench-key-proc
    ran 20000000 iterations in 6.623018074s

After:
    ran@ran:~/src/libxkbcommon$ ./test/bench-key-proc
    ran 20000000 iterations in 4.762291091s

Not that anyone needs to process millions of keys per second...

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

Use (1u << idx) instead of (1 << idx) where appropriate

It doesn't matter (I think), since the implicit conversion doesn't have
any effect (e.g. sign-extension). But it's better to be aware of the
type.

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

Use unsigned int for saving darray_size return value

See: b9b3593cbdeb7f5b02d50cecaba6a0b47d4979ad
So these should be unsigned int's now.

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

action: fix misleading cast

The type is uint8_t and so is the checked range.

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

action: fix printing of underflowed value in error message

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

scanner-utils: add some likely/unlikely annotations

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

Define likely()/unlikely() macros

It serves as nice "hotspot" annotations, and can also help things, so
why not.

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

Partially revert "ast: pack the ParseCommon struct"

This reverts commit 1e6e5669c6229846830f0b497591de4e3cf588eb.

It's probably safe, but let's not take any chances, as I don't have any
esoteric arch to test on. But keep the ATTR in case it's ever useful.

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

build: add -Wextra warnings

If it gets annoying, we can disable it. But for now it's clean.

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

ast: use more suitable types in a few ast nodes

The int ones cannot be signed (they come as such from the scanner, and
NEGATE is never applied to them).

The uint32_t one is really an atom, but presumably the type was never
converted to xkb_atom_t.

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