The CI started installing some wrapper instead of a real bash which is
what gets found.
See:
https://github.com/actions/virtual-environments/pull/1081
Given meson is written in python, it should always be available
hopefully.
Disabled valgrind wrapper for now because it now also applies to the
python interpreter which leaks like a sieve.
Signed-off-by: Ran Benita <ran@unusedvar.com>
We only ever care about whether we error out or not, so let's wrap this into
something more sane.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This library is the replacement for clients parsing evdev.xml directly.
Instead, they should use the API here so that in the future we may even
be able to swap evdev.xml for a more suitable data format.
The library parses through evdev.xml (using libxml2) and - if requested -
through evdev.extras.xml as well. The merge approach is optimised for
the default case where we have a system-installed rules XML and another file in
$XDG_CONFIG_DIR that adds a few entries. We load the system file first, then
append any custom ones to that. It's not possible to overwrite the MLVO list
provided by the system files - if you want to do that, get the change upstream.
XML validation is handled through the DTD itself which means we only need to
check for a nonempty name, everything else the DTD validation should complain
about.
The logging system is effectively identical to xkbcommon.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Returns true on success or false on error _or_ truncation. Since truncation is
almost always an error anyway, we might as well make this easier to check.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These were moved to tools/tools-common.c and now that all tools are switched
over, they're no longer needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move (sometimes duplicate) the required bits into new shared files
tools-common.(c|h) that are compiled into the internal tools library. Rename the
test_foo() functions to tools_foo() and in one case just copy the code of the
keymap compile function to the tool.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Passing -errno around and having separate labels depending on failure types is
superfluous here. All the unref calls can handle NULL and nothing cares about
errno once we're out of the immediate scope. So let's simplify this and deal
with 0 and 1 only.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Using test helpers to init the context gives it fairly specific behavior; unless
the user sets the right environment variables and/or calls it from the right
PWD, it may or may not include the test data.
Let's drop this behavior, make it a default tool to compile a keymap. If there
is a specific need to modify the include paths, we can add this later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit 16c84cdd81 removed the getopt handling for
RMLVO arguments, so now this tool only takes a keymap file and compiles it.
Using test helpers to init the context gives it fairly specific behavior; unless
the user sets the right environment variables and/or calls it from the right
PWD, it may or may not include the test data.
Let's drop this behavior, make it a default tool to compile a keymap. If there
is a specific need to modify the include paths, we can add this later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The unref() functions take NULL as argument, so we don't need different labels
for every possible exit path.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the active set of modifiers doesn't match any explicit entry of the
key type, the resulting level is 0 (i.e. Level 1). Some key types don't
explicitly map Level 1, taking advantage of this fallback.
Previously, xkb_keymap_key_get_mods_for_level didn't consider this, and
only reported masks for explicit mappings. But this causes some glaring
omissions, like matching "a" in the "us" keymap returning not results.
Since every mask which isn't explicitly mapped falls back to 0, we can't
return the all. Almost always the best choice for this is the empty
mask, so return that, when applicable.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/140.
Reported-by: https://github.com/AliKet
Signed-off-by: Ran Benita <ran@unusedvar.com>
The program takes a unicode codepoint and an RMLVO and prints out all
key + modifier combinations that would result in that codepoint.
The program was written to exercise the new
xkb_keymap_key_get_mods_for_level() function. It's handy and can be
extended in several ways, but enough for now.
Example:
$ ./build/how-to-type -l us,il,ru 0x41 | column -ts $'\t'
keysym: A (0x41)
KEYCODE KEY NAME LAYOUT# LAYOUT NAME LEVEL# MODIFIERS
38 AC01 1 English (US) 2 [ Shift ]
38 AC01 1 English (US) 2 [ Lock ]
38 AC01 2 Hebrew 2 [ Shift ]
38 AC01 2 Hebrew 2 [ Lock ]
$ ./build/how-to-type -l de -v neo 0x3b6 | column -ts $'\t'
keysym: Greek_zeta (0x7e6)
KEYCODE KEY NAME LAYOUT# LAYOUT NAME LEVEL# MODIFIERS
56 AB05 1 German (Neo 2) 4 [ Shift Mod5 ]
56 AB05 1 German (Neo 2) 4 [ Shift Mod2 Mod3 Mod5 ]
56 AB05 1 German (Neo 2) 4 [ Shift Lock Mod5 ]
56 AB05 1 German (Neo 2) 4 [ Lock Mod2 Mod3 Mod5 ]
Signed-off-by: Ran Benita <ran@unusedvar.com>
The new API is useful to implement features like auto-type and
desktop automation. Since the inputs for these features is usually
specified in terms of the symbols that need to be typed, the
implementation needs to be able to invert the keycode->keysym
transformation and produce a sequence of keycodes that can be used
to type the requested character(s).
In order to support features like auto-type and UI automation, the
relevant tools need to be able to invert the keycode->keysym->text
transformation. In order to facilitate that, a new API was added.
It allows querying the keysyms that correspond to particular Unicode
codepoints. For all practical purposes, it can be thought of as an
inverse of xkb_keysym_to_utf32().
This provides implementations of the test_enable_stdin_echo and
test_disable_stdin_echo which do not require <termios.h>, which is
not available on Windows.
Only the input/output functions from <unistd.h> options are used, so
using <io.h> when building with MSVC should be enough. The inclusion
of the header in context-priv.c does not seem to be needed (tested
on GNU/Linux) and so it is removed.
Signed-off-by: Ran Benita <ran@unusedvar.com>
The tests stringcomp and buffercomp do binary comparison on some files;
if the files are changed to CRLF on checkout, the tests fail.
Signed-off-by: Ran Benita <ran@unusedvar.com>
From MSVC:
test\atom.c(98): note: consider using '%zu' in the format string
test\atom.c(98): warning C4477: 'fprintf' : format string '%lu' requires an argument of type 'unsigned long', but variadic argument 1 has type 'size_t'
test\atom.c(100): note: consider using '%zu' in the format string
test\atom.c(100): warning C4477: 'fprintf' : format string '%lu' requires an argument of type 'unsigned long', but variadic argument 1 has type 'size_t'
test\atom.c(114): note: consider using '%zu' in the format string
test\atom.c(114): warning C4477: 'fprintf' : format string '%lu' requires an argument of type 'unsigned long', but variadic argument 1 has type 'size_t'
test\atom.c(128): note: consider using '%zu' in the format string
test\atom.c(128): warning C4477: 'fprintf' : format string '%lu' requires an argument of type 'unsigned long', but variadic argument 1 has type 'size_t'
test\atom.c(130): note: consider using '%zu' in the format string
test\atom.c(130): warning C4477: 'fprintf' : format string '%lu' requires an argument of type 'unsigned long', but variadic argument 1 has type 'size_t'
test\atom.c(137): note: consider using '%zu' in the format string
test\atom.c(137): warning C4477: 'fprintf' : format string '%lu' requires an argument of type 'unsigned long', but variadic argument 2 has type 'size_t'
Signed-off-by: Ran Benita <ran@unusedvar.com>
Previously we included it with an `-include` compiler directive. But
that's not portable. And it's better to be explicit anyway.
Every .c file should have `include "config.h"` first thing.
Signed-off-by: Ran Benita <ran@unusedvar.com>
The majority use-case for extending XKB on a machine is to override one or a
few keys with custom keycodes, not to define whole layouts.
Previously, we relied on the rules file to be a single file, making it hard to
extend. libxkbcommon parses $XDG_CONFIG_HOME/xkb/ but that only works as long
as there is a rule that matches the user-specified RMLVO. This works for MLV
but not for options which don't have a wildcard defined. Users have to copy
the whole rules file and then work from there - not something easy to extend
and maintain.
This patch adds a new ! include directive to rules files that allows including
another file. The file path must be without quotes and may not start with the
literal "include". Two directives are supported, %H to $HOME and %S for the
system-installed rules directory (usually /usr/share/X11/xkb/rules).
A user would typically use a custom rules file like this:
! option = symbols
custom:foo = +custom(foo)
custom:bar = +custom(baz)
! include %S/evdev
Where the above defines the two options and then includes the system-installed
evdev rule. Since most current implementations default to loading the "evdev"
ruleset, it's best to name this $XDG_CONFIG_HOME/xkb/rules/evdev, but any
valid name is allowed.
The include functionally replaces the line with the content of the included
file which means the behavior of rules files is maintained. Specifically,
custom options must be defined before including another file because the first
match usually wins. In other words, the following ruleset will not assign
my_model as one would expect:
! include %S/evdev
! model = symbols
my_model = +custom(foo)
The default evdev ruleset has wildcards for model and those match before the
my_model is hit.
The actual resolved components need only be in one of the XKB lookup
directories, e.g. for the example above:
$ cat $XDG_CONFIG_HOME/xkb/symbols/custom
partial alphanumeric_keys
xkb_symbols "foo" {
key <TLDE> { [ VoidSymbol ] };
};
partial alphanumeric_keys
xkb_symbols "baz" {
key <AB01> { [ k, K ] };
};
This can then be loaded with the XKB option "custom:foo,custom:bar".
The use of "custom" is just as an example, there are no naming requirements
beyond avoiding already-used ones. Also note the bar/baz above - the option
names don't have to match the component names.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This requires (well, at least implemented by) casting away `const` which
is undefined behavior, and clang started to warn about it.
The micro optimization didn't save too many allocations, anyway.
Signed-off-by: Ran Benita <ran@unusedvar.com>
A few lines above we check path_rel[0], so any null pointer will blow up
before we get here.
Found by coverity
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
python3 is always python3, but python could be python2 in some cases. Or just
missing (e.g. RHEL8).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This way stdin/stdout of the process are opened in text mode and we don't need
manually decode.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In python multiprocessing, each process needs to handle (and ignore) the
KeyboardInterrupt to avoid exception logging. This is a separate patch for
easier reviewing, the first hunks merely re-indent all of the
xkbcommontool/xkbcomp functions into a try/except KeyboardInterrupt block.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a change in behavior and requires any automated callers to adjust
accordingly. Still, much easier to get the errors that way rather than it
being mixed into a thousands-of-lines output file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Collect all options into a dictionary, then process that as async actions
through a process pool. This of course requires collecting the various print
statements to avoid mangled output.
This dropped the time to completion from around 14 min to 8 min on my local
machine (unscientific single run only for the original timing).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All tests create a temporary directory, set up the environment for that
directory and then check the include paths for the presence of that directory,
ideally in the right position of the list.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xkbcomp only accepts the "Level" prefix for a level name for levels 1 to
8, but the keymap dumping code added it always, e.g. "Level15".
The plain integer, e.g. "8", "15" is always accepted, so just use that.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/113
Signed-off-by: Ran Benita <ran@unusedvar.com>
Reported-by: progandy
xdg_shell v6 was pretty close to the finalised stable version of
xdg-shell. We can now just use the stable version, which is supported
everywhere (Enlightenment, KWin, Mutter, Weston, wlroots).
This requires bumping the wayland-protocols dependency.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This test contains of two parts:
- a simple program to convert RMLVO commandline arguments into a keymap (and
print that keymap if requested).
- a python script that runs through rules/evdev.xml, and tries to compile a
keymap for sort-of every layout/variant/option combination. Sort-of, because
we can have multiple options and it really only does one per layout(variant)
combination.
Same thing can be done using xkbcomp, but right now it doesn't take that as
argument, it's hard-coded.
This takes quite a while, installing python-tqdm is recommended to see fancy
progress bars instead of just miles of dumps.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Can happen in cases like:
- There was an error between the error check and the call.
- The internal poll() fails.
Signed-off-by: Ran Benita <ran234@gmail.com>
The enum seems large, and we don't handle all of the values in it.
Previously if we got an unrecognized SHM format we would use an
uninitialized `stride`.
Signed-off-by: Ran Benita <ran234@gmail.com>
Mutter only implements v6 now, and Weston also implements that. Port
interactive-wayland to this so people can keep on using it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We currently use strcasecmp, which is locale-dependent. In particular,
one well-known surprise even if restricted just ASCII input is found in
the tr_TR (Turkish) locale, see e.g.
https://msdn.microsoft.com/en-us/library/ms973919.aspx#stringsinnet20_topic5
We have known to avoid locale-dependent functions before, but in this
case, we forgot.
Fix it by implementing our own simple ASCII-only strcasecmp/strncasecmp.
Might have been possible to use strcasecmp_l() with the C locale, but
went the easy route.
Side advantage is that even this non-optimized version is faster than
the optimized libc one (__strcasecmp_l_sse42) since it doesn't need to
do the locale stuff. xkb_keysym_from_name(), which uses strcasecmp
heavily, becomes faster, and so for example Compose file parsing, which
uses xkb_keysym_from_name() heavily, becomes ~20% faster.
Resolves https://github.com/xkbcommon/libxkbcommon/issues/42
Signed-off-by: Ran Benita <ran234@gmail.com>
The current functions dealing with consumed modifiers use the
traditional XKB definition of consumed modifiers (see description in the
added documentation). However, for several users of the library (e.g.
GTK) this definition is unsuitable or too eager. This is exacerbated by
some less-than-ideal xkeyboard-config type definitions (CTRL+ALT seems
to cause most grief...).
So, because we
- want to enable alternative interpretations, but
- don't want to expose too much internal details, and
- want to keep things simple for all library users,
we add a high-level "mode" parameter which selects the desired
interpretation. New ones can be added as long as they make some sense.
All of the old consumed-modifiers functions keep using the traditional
("XKB") mode. I mark xkb_state_mod_mask_remove_consumed() and as
deprecated without adding a *2 variant because I don't it is very useful
(or used) in practice.
Alternative modes are added in subsequent commits (this commit only adds
a mode for the existing behavior).
https://github.com/xkbcommon/libxkbcommon/issues/17
Signed-off-by: Ran Benita <ran234@gmail.com>
Takes care of GCC's annoyingly persistent warn_unused_result warnings.
But it's better to avoid system() I suppose.
Signed-off-by: Ran Benita <ran234@gmail.com>
More meticulously free everything we create, including hooking up the
buffer-release callback so we actually free those when required. Make
sure seats are actually in the display's seat list.
The xkbcommon object-unref functions don't actually require
NULL-checking, so we can elide those.
Signed-off-by: Daniel Stone <daniels@collabora.com>
interactive-wayland is very similar to x11/xev, and dumps out as much
state as possible.
It provides no titlebar and a completely random cursor, but such is
life.
Signed-off-by: Daniel Stone <daniels@collabora.com>
xkb_keymap_key_by_name() allows finding a keycode from a given keyname and
is useful for generating keyboard events to use in regression tests
during CI
xkb_keymap_key_get_name() is the inverse of xkb_keymap_key_by_name()
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
[ran: some stylistic tweaks + another test case]
Signed-off-by: Ran Benita <ran234@gmail.com>
The `test/data/keymaps/host.xkb` file contains a duplicate definition of
this type. On my computer (linux, xkbcomp 1.3.0, xserver 1.17.2), the
test passes as is, but if I remove the duplicate definition, the
roundtrip brings it back and the test fails. I can also reproduce it
without relation to the test, by loading `test/data/keymaps/host.xkb`
(without the duplicate) using
xkbcomp -I $(pwd)/test/data/keymaps/host.xkb $DISPLAY
and downloading it again using
xkbcomp $DISPLAY out.xkb
the duplicate is added. On Mac OS X however, the duplicate is removed
(correctly), so the test fails there.
xkbcommon itself, which was forked from xkbcomp, doesn't have this bug;
in fact, doing
./test/print-compiled-keymap -k keymaps/host.xkb
removes the duplicate if it is present.
This is (probably) a regression in xkbcomp or xserver compared to the
versions used in Mac OS X. Since getting a patch for any of these two is
hopeless from my experience, I did not try to investigate further.
I am not sure why, but if I also add a `PC_SUPER_LEVEL2` type, the
duplicate of `FOUR_LEVEL_KEYPAD` doesn't show up. Hopefully the test
will work on all platforms now.
https://github.com/xkbcommon/libxkbcommon/issues/26
Reported-by: @nuko8
Signed-off-by: Ran Benita <ran234@gmail.com>
xkbcomp doesn't need the search-path argument, since we pass an absolute
path. Keep the plain -I which clears the search path just to be sure.
Signed-off-by: Ran Benita <ran234@gmail.com>
Some results from the benchmark (compilation of en_US.UTF-8/Compose):
$ grep 'model name' /proc/cpuinfo
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
$ uname -a
Linux ran 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux
$ ./test/compose bench
compiled 1000 compose tables in 7.776488331s
So according to the above benchmark and valgrind --tool=massif, an
xkb_compose_table adds an overhead of about ~8ms time and ~130KB
resident memory.
For contrast, a plain US keymap adds an overhead of ~3ms time and 90KB
resident memory.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
- 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>
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.
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>
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>
Add two tests:
./test/interactive-x11
which is like test/interactive-evdev, but should behave exactly like your
X keyboard and react to state and keymap changes - in other words, just
like typing in xterm. Press ESC to exit.
./test/x11
which currently should only print out the same keymap as
xkbcomp $DISPLAY out.xkb
(modulo some whitespace and some constructs we do not support.)
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
Someone was nice enough to run this for us:
ftp://ftp.sunet.se/pub/Linux/distributions/Debian/debian/pool/main/libx/libxkbcommon/libxkbcommon_0.3.1.orig.tar.gz
[libxkbcommon-0.3.1/src/keymap.c:86]: (style) The scope of the variable 'j' can be reduced.
[libxkbcommon-0.3.1/src/keymap.c:87]: (style) The scope of the variable 'key' can be reduced.
[libxkbcommon-0.3.1/src/keysym-utf.c:843]: (style) The scope of the variable 'mid' can be reduced.
[libxkbcommon-0.3.1/src/state.c:992]: (style) The scope of the variable 'str' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/action.c:467]: (style) The scope of the variable 'absolute' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:468]: (style) The scope of the variable 'consumed' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:862]: (style) The scope of the variable 'mlvo' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:863]: (style) The scope of the variable 'kccgst' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:865]: (style) The scope of the variable 'match_type' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/symbols.c:753]: (style) The scope of the variable 'toAct' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/symbols.c:1573]: (style) The scope of the variable 'key' can be reduced.
[libxkbcommon-0.3.1/test/common.c:80]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'.
[libxkbcommon-0.3.1/test/interactive.c:358]: (style) The scope of the variable 'nevs' can be reduced.
[libxkbcommon-0.3.1/test/interactive.c:236]: (style) Checking if unsigned variable 'nsyms' is less than zero.
[libxkbcommon-0.3.1/test/interactive.c:226]: (style) Unused variable: unicode
Signed-off-by: Ran Benita <ran234@gmail.com>
1000 is a bit too low for statistical significance on this 6 years old
CPU. Since the benchmark is run manually this shouldn't be a problem.
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>
Kind of odd, but get_one_sym() will be getting a different behavior.
Real life users *should* pick one or the other.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is too strict, and causes symbols/cz to fail parsing. Instead, just
emit a warning (not shown by default):
xkbcommon: WARNING: cz:75:19: unknown escape sequence in string literal
https://bugs.freedesktop.org/show_bug.cgi?id=68056
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Some keymaps actually have this, like the quartz.xkb which is tested. We
need to support these.
https://bugs.freedesktop.org/show_bug.cgi?id=67654
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
We should handle empty xkb_keycode and xkb_symbol sections, since
xkbcomp handles them, and apparently XQuartz uses it. There are also
files for it in xkeyboard-config (rules=base model=empty layout=empty,
which translate to keycodes/empty and symbols/empty).
https://bugs.freedesktop.org/show_bug.cgi?id=67654
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Peter Hutterer
Nils
Jaroslaw Kubik
Adrian Perez de Castro
Ran Benita
worldofpeace
Daniel Stone
Naman Dixit
Mike Blumenkrantz
Kazunobu Kuriyama
Pino Toscano
Jasper St. Pierre