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>
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>
Peter Hutterer
Ran Benita
Nils