Where a fuzz is defined in the 60-evdev.hwdb, we rely on a udev builtin to
set the kernel device to that fuzz value. Unfortunately that happens after our
program is called with this order of events:
1. 60-evdev.rules calls IMPORT(builtin) for the hwdb which sets the EVDEV_ABS_*
properties. It also sets RUN{builtin}=keyboard but that's not invoked yet.
2. 90-libinput-fuzz-override.rules calls IMPORT{program} for our fuzz override
bits. That sets the kernel fuzz value to 0 and sets the LIBINPUT_FUZZ_*
propertie
3. The keyboard builtin is run once all the rules have been processed.
Our problem is that where the fuzz is set in a hwdb entry, the kernel fuzz is
still unset when we get to look at it, so we always end up with a fuzz of zero
for us and a nonzero kernel fuzz.
Work around this by checking the EVDEV_ABS property, extracting the fuzz from
there and re-printing that property without the fuzz. This way we ensure the
kernel remains at zero fuzz and we use the one from the hwdb instead.
Fixes#346
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput-util.h is getting a bit of a catchall bucket and it includes things
like libinput-private.h which in turn includes libwacom. This makes
libinput-util.h less useful for bits that only need e.g. the string processing
utilities.
So let's split them all up in to separate files, to be used as-needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These tests include string parsers, definitely want those to run under
valgrind to detect OOB reads and writes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This isn't technically needed since those tests aren't in the valgrind test
suite anymore. But let's have it here anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This header is intended to be included in the project, so let's do that and
have proper runtime detection of the valgrind environment.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All the bits that test for utility functions to work correctly can be run
separately from the main test suite (which tests devices and libinput in
general). These bits here are the ones that test the code itself and aren't
reliant on anything else.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
