This is hit when passing an empty string and XKB_KEYSYM_CASE_INSENSITIVE
to xkb_keysym_from_name currently if `(lo + hi) / 2` is 0 and `cmp < 0`,
causing mid to underflow and the the array access into name_to_keysym on
the next iteration of the loop to be out of bounds .
We *would* use ssize_t here as it is the appropriate type, but windows
unfortunately does not define it.
Add a skipError test function that can analyse rc, stdout, stderr to skip a test
even when we expect an error. We use that to skip if we couldn't find a keyboard
in the interactive-evdev test.
Fixes#235
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tqdm prints to stderr by default but we're using that for failed keymap
compiles (which are the ones that really matter). Plus, whether we're using tqdm
is dependent on isatty(sys.stdout) anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With --keymap-output-dir, the given directory will contain a list of files named
after the layout + variant ('us', 'us(euro)', ...) that contain the keymaps for
each variant + option combination compiled.
This is still a lot, but better to sift through hundreds of keymaps than tens of
thousands.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous output is largely unusable. The result in the CI test runs is a 6GB
file with every compiled keymap in it and while we can grep for ERROR, it's not
particularly useful.
Let's change this and print out YAML instead - that can be machine-processed.
This patch adds a new parent class that prints itself in YAML format,
the tool invocations are child classes of that class. The result looks like this:
Example output:
- rmlvo: ["evdev", "pc105", "us", "haw", "grp:rwin_switch"]
cmd: "xkbcli-compile-keymap --verbose --rules evdev --model pc105 --layout us --variant haw --options grp:rwin_switch"
status: 0
- rmlvo: ["evdev", "pc105", "us", "foo", ""]
cmd: "xkbcli-compile-keymap --verbose --rules evdev --model pc105 --layout us --variant foo"
status: 1
error: "failed to compile keymap"
Special status codes are: 99 for "unrecognized keysym" and 90 for "Cannot open
display" in the setxkbmap case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Relatedly, strtoul allows a lot of unwanted stuff (spaces, +/- sign,
thousand seperators), we really ought not use it. But that's for another
time.
Signed-off-by: Ran Benita <ran@unusedvar.com>
A simple script that creates a new layout with the given keysym replacing TLDE.
Then we compile a keymap and search for the keysym being assigned to TLDE and
bail if that fails.
The list of keysyms is manually maintained but we only need to add one or two to
spot-check whenever the xorgproto is updated.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
rmlvos is the parent list which then fails during a list join because, well,
it's a list of lists.
Fixes#206
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Makes this test easier to run from the commandline. Where either of top_srcdir
or top_builddir isn't set, fill them in from the CWD or fail otherwise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where resolve_keysym fails we warn but use the otherwise uninitialized variable
as our keysym. That later ends up in the keymap as random garbage hex value.
Simplest test case, set this in the 'us' keymap:
key <TLDE> { [ xyz ] };
And without this patch we get random garbage:
./build/xkbcli-compile-keymap --layout us | grep TLDE:
key <TLDE> { [ 0x018a5cf0 ] };
With this patch, we now get NoSymbol:
./build/xkbcli-compile-keymap --layout us | grep TLDE:
key <TLDE> { [ NoSymbol ] };
For me, installing pytest for libxkbcommon is a bit problematic, so I
end up skipping it which is not great.
Switch to unittest which is built in to Python. It's not as nice as
pytest but good enough in this case.
Note: I was too lazy to switch the plain asserts to unittest
assertions...
Signed-off-by: Ran Benita <ran@unusedvar.com>
mkdtmp, rmdir and unlink are in unstd.h on MacOS. Since including that it
doesn't hurt us on Linux, let's do it without ifdefs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This completes the usual triplet of configuration locations available for most
processes:
- vendor-provided data files in /usr/share/X11/xkb
- system-specific data files in /etc/xkb
- user-specific data files in $XDG_CONFIG_HOME/xkb
The default lookup order user, system, vendor, just like everything else that
uses these conventions.
For include directives in rules files, the '%E' resolves to that path.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
'xkbcli compile-keymap' doesn't work unless we ninja install first. But for a
test that's to be run from the test directory, that's not a useful option so
let's call the binary directly. The script adds the meson builddir to the PATH
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let's not have our tests fail if the user has an incompatible
$XDG_CONFIG_HOME/xkb directory.
libxkbcommon has fallbacks when XDG_CONFIG_HOME isn't set so we need to override
this with a real directory instead of just unsetting it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The xkbcli tool usage help is ifdef'd out where the tool isn't built but the
man page always includes all tools. Easier that way.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Python leaks like crazy when run under valgrind. But if we make the script
executable **and** it has uses the env invocation (i.e. #!/usr/bin/env python3),
the leaks disappear. This is not the case for a shebang of /usr/bin/python3.
Why exactly this is the case I'm not sure but executables we plan to run
should have the exec bit set. So this is a janitor patch with the nice side
effect of fixing our valgrind runs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Ran Benita
Isaac Freund
Peter Hutterer