SIGQUIT which we send to any successful test of libinput debug-event will
trigger a coredump. We don't need that one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Just use the wait() timeout directly instead of sleep and kill. This allows us
to have a longer timeout and still get fast handling where the tool
immediately exits, but less failure when running on busy machines.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not sure how this ever worked correctly: a process terminated by a signal has
the negative signo as return code. This would apply to every debug-events and
debug-gui test because they have to get killed by a signal. This failed
occasionally, presumably a race with the GTK startup/signal handler/whatever.
Fix this by a) sending SIGQUIT because that won't get handled by the tools and
b) prending that if we get a -SIGQUIT exit code, everything is fine.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Pass arguments we don't handle directly through to the unittest module. This
way we can filter tests with -k testname etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the most common use-case other than "all from udev", so let's just
parse a device path correctly without requiring --device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't check for correctness in the output as such, just that whatever
combination of cmdline arguments still works/doesn't work. This is the
scaffolding and a few tests, but needs to be filled in, especially for
libinput measure and for some more complex combinations.
valgrind: requires one more python-related suppression
gitlab-ci: requires another environment variable so we know to skip the
--device tests (udev will time out on those)
meson: skip the test run in release builds, we pass the full path to the built
libinput tool but rely on the subtool lookup that won't work in a
release build
Fixes#174
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
