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>
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>
