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>
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>
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>
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.
These functions also return -1 on invalid input. The original tests
didn't check that, but used !tests instead. Since then we've changed
them, but some were missed, and for some we forgot to remove the ! (or
you can say they were extra clever).
Signed-off-by: Ran Benita <ran234@gmail.com>
The xkbproto spec says:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Lock_Modifier
If the Lock modifier is not consumed by the symbol lookup process,
routines that determine the symbol and string that correspond to
an event should capitalize the result.
This was not an issue until now, because most xkeyboard-config keymaps
do not utilize this "feature", and specify the keysyms for the Lock
modifier explicitly instead. However, some keymaps do depend on it, e.g.
ch(fr) for eacute and others.
The spec goes on to describe two options for doing this transformation:
locale-sensitive and locale-insensitive. We opt for the latter; it is
less desirable but we don't want *that* headache.
Also, only xkb_state_key_get_one_sym() is changed;
xkb_state_key_get_syms() is left as-is, and always reports the
untransformed keysyms. This is for the following reasons:
- The API doesn't allow it, since we return a const pointer directly to
the keymap keysyms table and we can't transform that.
- The transformation doesn't make sense for multiple-keysyms.
- It can be useful for an application to get the "raw" keysyms if it
wants to (e.g. maybe it wants to do the transformation itself).
Finally, note that xkb_state_mod_index_is_consumed() does *not*
report Lock as consumed even if it was used in the transformation. This
is what Xlib does.
This definitely doesn't fall under the "hard to misuse" API rule but
it's the best we can do.
https://bugs.freedesktop.org/show_bug.cgi?id=67167
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Add three new pieces of API:
- xkb_keymap_min_keycode does what it says on the tin
- xkb_keymap_max_keycode likewise
- xkb_keymap_key_for_each calls the provided function once for every
valid key in the keymap
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For error handling code, it's nice to be able to pass NULL to these
function without worrying about segfaults ensuing. free() sets the
precedent here.
Also document this fact.
Signed-off-by: Ran Benita <ran234@gmail.com>
Note first:
This commits breaks the ABI somewhat. If an application is run against
this commit without recompiling against the updated header, these break:
- xkb_state_layout_*_is_active always retuns false.
- xkb_state_serialize_mods always returns 0.
So it might break layout switching in some applications. However,
xkbcommon-compat.h provides the necessary fixes, so recompiling should
work (though updating the application is even better).
Split the enum to its individual components, which enables us to refer
to them individually. We will use that later for reporting which
components of the state have changed after update.
Signed-off-by: Ran Benita <ran234@gmail.com>
Currently xkb_keymap_num_leds() returns a count of valid (settable)
leds. Because the indexes might be non-consecutive, and some leds
might not be settable, it is incorrect to use this function for
iterating over the leds in the keymap. But this is the main use case of
this function, so instead of the current behavior we adapt the function
to the use case by making it return the needed range of iteration.
The caller needs to handle invalid intermittent indexes, though.
Signed-off-by: Ran Benita <ran234@gmail.com>
xkb_keymap_num_leds() returns the number of leds that have any
possibility of being set. Even if a led is defined but can not be set in
any way, it is not counted.
In a few places currently we assume that led indexes are smaller than
this number, which is wrong both for the above reason and for the fact
that the xkb format actually allows explicitly setting the indicator
index, which means that the indexes might be non-consecutive.
We don't really have good API to iterate on leds, now, because
xkb_keymap_num_leds is pretty useless. To work around that we use
sizeof(xkb_led_mask_t) * 8.
This makes the "Group 2" led work (try switching to a layout other than
the first in test/interactive).
Signed-off-by: Ran Benita <ran234@gmail.com>
This is a regression introduced in ed78fbcb30.
XKB_STATE_EFFECTIVE is just a OR of the other states, so using & here is
completely wrong. So test/state shows for example:
dumping state for LCtrl down:
group English (US) (0): effective depressed latched locked
mod Control (2): depressed latched locked
dumping state for LCtrl + RAlt down:
group English (US) (0): effective depressed latched locked
mod Control (2): depressed latched locked
mod Mod1 (3): depressed latched locked
dumping state for RAlt down:
group English (US) (0): effective depressed latched locked
mod Mod1 (3): depressed latched locked
dumping state for Caps Lock:
group English (US) (0): effective depressed latched locked
mod Lock (1): depressed latched locked
led Caps Lock (0): active
dumping state for Alt-Shift-+
group English (US) (0): effective depressed latched locked
mod Shift (0): depressed latched locked
mod Mod1 (3): depressed latched locked
which is bogus.
Signed-off-by: Ran Benita <ran234@gmail.com>
This function was always returning -1.
Adding a test, we see that test/state.c treat the is_active functions as
returning booleans, which would treat -1 as success, so we test for > 0
instead (most users would probably get this wrong as well...).
Also update the documentation for the are_active functions, and add a
ATTR_NULL_SENTINEL for gcc __attribute__((sentinel)).
Signed-off-by: Ran Benita <ran234@gmail.com>
A fairly simple helper which, given an xkb_mod_mask_t, removes all
modifiers which are consumed during processing of a particular key.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Including creating a context (will come in useful soon), opening and
reading files, and compiling keymaps.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For the darray we need to specify the explicit struct xkb_filter type
instead of void*, so we move the definition of struct xkb_state into
state.c thus making it opaque even from the rest of the files. It has
enough getters to get going and is otherwise good style.
Signed-off-by: Ran Benita <ran234@gmail.com>
Still keep things as 'ctx' internally so we don't have to worry about
typing it too often, but rename the user-visible API back as it was
kinda ugly.
This partially reverts e7bb1e5f.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
(This breaks the API.)
"context" is really annoying to type all the time (and we're going to
type it a lot more :). "ctx" is clear, concise and common in many other
libraries. Use it!
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Fix for xkb -> keymap change.]
Two new calls allow users to test the exact modifier state, including
verifying that no other modifiers but the ones you wanted are down.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
xkbcommon-names.h right now just contains a set of hardcoded modifier
strings that are most commonly used for the usual modifiers. Provide
definitions of these so people don't have to worry about typoing a
string or mixing up Mod1 and Mod4.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Make the files in the src/* directory use their own header or a
consilidated private header. This makes the file dependencies clearer.
Also drop the pointless "xkb" file name prefix, add split a few
declarations to their own files (atom.h and text.h).
Signed-off-by: Ran Benita <ran234@gmail.com>
Rewrite all of the current tests in the following ways:
- Instead of the current mix of C and shell, just use single-process
pure C file per test. All of the .sh files are removed, but everything
that was tested is ported.
- Instead of handling the test logs ourselves, use Automake's
"parallel-test" mechanism. This will create a single log file for each
test with it's stdout+stderr, and a top level "test-suite.log" file
for all the failed tests.
- The "parallel-tests" directive also makes the test run in parallel,
so "make check" runs faster.
- Also use the "color-tests" directive to have the "make check" output
colorized. Who doesn't like to see PASS in green?
- All of the test data files are moved into the test/data subdirectory.
That way we can just put the directory in EXTRA_DIST and forget about
it.
- The test/Makefile.am file is consolidated into the main Makefile.am,
for a completely non-recursive build.
Right now the tests are completely independent and just use simple
assert()'s. More sophistication can be added as needed.
It should also be noted that it's still possible to use shell, python,
etc. if a test wants more flexibility than C can provide, just do as
before.
Signed-off-by: Ran Benita <ran234@gmail.com>
[daniels: Updated for xkb_keymap changes.]
Since we define our own xkb_atom_t type, it makes sense not to use the
X11/X.h None value. This way we can also remove a lot of X11 includes.
Signed-off-by: Ran Benita <ran234@gmail.com>
Use XKB_KEY_UP instead of 0 and XKB_KEY_DOWN instead of 1.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: Ran Benita <ran234@gmail.com>
And also convert state.c to use the state API for mods and groups,
rather than testing the state members directly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Add new API to deal with xkb_state objects, including
xkb_state_update_key, which runs the XKB action machinery internally to
calculate what exactly happens to the state when a given key is pressed
or released.
The canonical way to deal with keys is now:
struct xkb_state *state = xkb_state_new(xkb);
xkb_keysym_t *syms;
int num_syms;
xkb_state_update_key(state, key, is_down);
num_syms = xkb_key_get_syms(state, key, &syms);
More state handling API, including a way to get at or ignore preserved
modifiers, is on its way.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita
Jasper St. Pierre
Matthias Clasen
Daniel Stone
Kristian Høgsberg