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>
Allows for reproducible builds. Debian carries a patch for this, and the
timestamp doesn't really add much since the doc is either in sync with master
or represents the release tag. Might as well drop it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previous ones used the absinfo from the kernel but since we never updated that
from within the tool, the output was always the same.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Filter them immediately instead of passing them on and relying on the actual
event handling code to filter them.
Reproducer: if EV_ABS is disabled on an Apple MagicMouse we still get events
passed into sanitize_event(). But the code handling EV_ABS events doesn't
update the state, so we end up complaining about double tracking IDs, even
though that is not actually correct.
https://bugzilla.redhat.com/show_bug.cgi?id=1361325
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Almost no-one does the calculations for me to update the udev rules (and some
rules were submitted with the <x resolution> placeholders left in).
Require the user to specify the physical size so we just copy/paste the actual
udev rule.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Available in kernel 4.5 and later (uinput version 5), these ioctls allow us to
set the absinfo correctly, i.e. including the resolution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
No functional changes. This is prep work for supporting the new
UIDEV_DEV_SETUP ioctl.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The kernel has split most of the event codes out to a new header but the FF_
bits are missing from that header. Until this is fixed upstream, change the
event code parsing so it can take two files (using cat and stdin) so we can
update the kernel headers again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We abort if anything goes wrong anyway, so we never returned anything but
success.
Found by coverity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
