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>
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>
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>
Some devices scale the frequency based on the input and will provide
recordings with different frequencies each time. Recommend to measure multiple
times since we can only know what the highest frequency is.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Relative devices don't provide a physical resolution to the host. For things
like pointer acceleration, the physical amount of movement is better as
baseline than the movement in device units.
Alas, many devices don't come with any information at all, so the users have
to guess. Help that guesswork by providing a tool that does the calculations
for them.
This tool measures the device units covered, then prints the frequency and an
lookup table for various resolutions (in dpi) to match to the physical
movement of the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
