Looks like this isn't needed, see #112. Or Lenovo re-used USB IDs for this
device in which case we'll have to figure out some other solution once someone
complains.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/112
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, we had a hard threshold of 20mm per event frame. That is just
about achievable by really fast movements (in which case you don't care too
much about the jumps anyway because you've already hit the edge of the screen).
Sometimes pointer jumps have lower deltas that are achievable even on slower,
more likely motions. Analysis of finger motion has shown that while a delta
>7mm per event is possible, jumping _by_ 7mm between two events is unlikely
and indicates a pointer jump. So let's diff the most recent delta and the
current delta, if it increases by 7mm between two event frames let's say it's
a pointer jump and discard it.
Helps with but does not fully resolve:
https://gitlab.freedesktop.org/libinput/libinput/issues/80https://gitlab.freedesktop.org/libinput/libinput/issues/36
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, anything that's in the top/bottom area but not in the
respective middle/right area is a left button.
Introduced by 13bda5adcb
Fixes coverity complaint about use of uninitialized variable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The software button area is currently a partially-dead area. If the finger
moves into or out of the area pointer motion works. Finger motion within the
area however does not generate motion.
The main motivation for this was to avoid accidental pointer motion when a
button is pressed. This is required for stationary fingers but once you move a
significant distance, those bets are off.
So if the finger moves by more than 5mm from where it was put down, release it
and let it move the pointer.
The full impact is largely limited to horizontal movements within the button
area because:
- leaving the finger at the bottom area for 300ms without movement triggers
the thumb identification, so it won't move anyway.
- moving the finger north is likely to go off the button area before we
trigger this threshold.
https://gitlab.freedesktop.org/libinput/libinput/issues/86
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least not opening single quotes, same as the double quotes we already have.
Add the tests for both.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't have a sensible use case where we want hex to double, or INF to
double, or any of that. So check the strings for invalid characters and bail
out early. Invalid characters include 'e' and whitespaces too, we don't need
those.
Small chance of things breaking: if the user-exposed calibration matrix
property was specified using hex numbers this will stop working now. I'll take
that risk.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let's use something that specializes in that task and does a better job of it
than whatever we'll come up with. Due to how it's implemented the stacktrace
will always show waitpid() as frame 0 now but we can live with that.
gstack prints to stdout but litest_log() uses stderr, so we cannot just call
system(), we have do do the pipe/fork/exec/waitpid/read dance.
We could use that to filter the #0 frame showing waidpid() from gstack but
meh.
This drops the libunwind and addr2line dependency and replaces it with gstack
instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No need to rebuild everything with an ifdef, we can just use meson to pass an
argument to the test itself and filter based on that. This drops about 100
ninja targets.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of calling out to install on every ninja call, use @PLAINNAME@ as
substitution for just copying the file over. This gets around the "no
directory allowed in output file" limitation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes two-finger scrolling in straight lines easier, while still
allowing free/diagonal movement. It works in three stages:
1) Initial movement
- For the first few millimeters, scroll movements within 30 degrees
of horizontal or vertical are straightened to 90-degree angles.
- Scroll movements close to 45 degree diagonals are unchanged.
- If movement continues very close to straight horizontal or
vertical, stage 2 begins and the axis lock engages.
- If movement continues along a diagonal, stage 2 is skipped and
free scrolling is immediately enabled.
2) Axis lock
- If the user scrolls fairly closely to straight vertical, no
horizontal movement will happen at all, and vice versa.
- It is possible to switch between straight vertical and straight
horizontal, and the axis lock will automatically change.
- If deliberate diagonal movement is detected at any point, stage
3 begins and the axis lock disengages.
3) Free scrolling
- Scrolling is unconstrained until the fingers are lifted.
No touchpad gives us these events with a 0 delay, so let's not test for that.
This is required for adding timing-sensitive scroll code, see
https://gitlab.freedesktop.org/libinput/libinput/issues/101.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having this as the generic "synaptics" touchpad in the tests is not helpful,
this touchpad is tiny and quite special these days.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use the same blurb everywhere, changing from the old style MIT to the Expat
license we're using everywhere else.
Similar to bc9f16b40e
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the trackpoint gives us deltas with less than 10ms intervals, something is
wrong. Could be bad hardware, a glitch in the matrix or a discontinuity in
the otherwise appropriately named time-space continuum. Usually it's the
first.
Let's always set up trackpoint delta smoothening for 10ms to improve the
pointer speed calculation and avoid jerky behaviors. i.e. if a trackpoint
delta comes in below 10ms, pretend it came in with a 10ms interval for
calculating the speed.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/104
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first event we receive is set to a 0ms offset anyway. Setting last_ms to 0
on the first event means the first two events have +0ms offset printed to the
log. Skip it, so the second event has the right offset.
This is human-readable data only, no effect on the recording file itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
