This flag was used to disable test runs during make distcheck. Now that we
have more checks and the environment variable, we can drop this flag.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Presumably this worked, but it certainly doesn't work anymore (neither on
RHEL7 nor on Fedora 28)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Depending on the container, or other checks don't always work. Add an extra
environment variable instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We previously had this separate because it tested separate things. Now the
setup is generic enough that we should just re-use it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Even if we're root we may be running in a container without input device
nodes. In which case we should skip the test, not fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It's not really autodetection, we just declare the test suites that need root
privs. But this way we can generically check for it from the main() that we
re-use across tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move all tests to a special section, then loop through that section
to fetch all test suite. The result is that new tests only need to add the
source files without having to update everything else as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The struct input_event is not y2038 safe.
Update the struct according to the kernel patch:
https://lkml.org/lkml/2018/1/6/324
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They have the same value, so the _MAX code would shadow the real code, causing
issues in any client that needs to get all event names from libevdev.
Specifically, the loop of:
for each code in 0 to max-for-type:
print(name)
would not show up the code (but the _MAX) code instead. This causes issues
with clients that rely on name resolution that works. And the _MAX values are
special values anyway.
Blacklist it in the script here, causing it to resolve from name to code, but
not from code to name (like other duplicated codes).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
They have the same value, so the _MAX code would shadow the real code, causing
issues in any client that needs to get all event names from libevdev.
Specifically, the loop of:
for each code in 0 to max-for-type:
print(name)
would not show up the code (but the _MAX) code instead. This causes issues
with clients that rely on name resolution that works. And the _MAX values are
special values anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
leftover from when this was part of evemu
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Previously, calling grabbing a device after changing the fd was a no-op
because libevdev's grab state didn't match the fd:
libevdev_grab(LIBEVDEV_GRAB);
.. fd is grabbed
.. internal state is 'grabbed'
libevdev_change_fd();
.. new fd is ungrabbed
.. internal state is 'grabbed'
libevdev_grab(LIBEVDEV_GRAB);
.. argument matches internal state and we exit without grabbing the device
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes the warning:
../libevdev/libevdev-int.h:231:15: warning: argument 1 value
‘18446744073709551615’ exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
That's now part of gcc's -Wall, so let's rely on that for code. Arguably, the
queue code is simple enough that we don't need a test for ENOMEM anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Not needed, so let's get rid of the compiler warning.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It's a test suite, it shouldn't fill up the file system or the journal with
coredumps.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Beats crashing by dereferencing a null-pointer (when we access
m->frequencies[idx])
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The main thing holding us back here was our gcov hacks. We used to rebuild the
libevdev sources locally inside test/ with the gcov flags so that we could
leave the main libevdev sources untouched. This doesn't work well with
subdir-objects - we have to link to libevdev.la instead.
To enable gcov, we now have to apply the gcov flags to the main library
object. But this also means that when running, the notes files will be
somewhere within the libevdev/ directory, not the test/ directory. Working
around this in automake gets nasty quickly, so just add a script that knows
how to search for things.
No functional changes unless --enable-gcov is given at configure time - then
don't install the library.
The gcov reports are now in test/gcov-reports/
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The tests all need root, but running distcheck as root is not ideal. Disable
the test runs (but not the build) to make it easier to verify distcheck works
as intended.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The incorrect variable was checked as a return code in an example, and
that can be confusing for people trying to learn or use the example code
as a starting point.
And if they're 30% out, print a warning. On the ThinkPad X1 Wireless Touch
Mouse (when connected via bluetooth) we get a bunch of events at the start of
the movement, all less than 1ms apart. Best guess is that the device goes to
low-power, then notices the movement and buffers the event until the BT
connection is back up. Then it sends all events at once. Usually they're less
than 1ms apart, but at one recording showed a 37ms delay before we go back to
the normal 70ms (~15Hz) the mouse has otherwise.
This is unpredictable enough that we can't just work around it so instead
print a warning to the user so they can go investigate.
https://bugs.freedesktop.org/show_bug.cgi?id=97812
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Side-effect of 240ba34ebd was that "touchpad size as listed by the kernel"
was now dependent on the values we got. This one is a static one based on the
axis info.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
