There are 4 possible cases why a touchpad suspends right now: lid switch,
tablet mode switch, sendevents disabled and sendevents disabled when an
external mouse is present.
But these reasons can stack up, e.g. a lid switch may happen while send events
is disabled, disabling one should not re-enable the touchpad. This patch adds
a bitmask to remember the reasons we're current suspended, resuming only
happens once all reasons are back to 0.
https://bugs.freedesktop.org/show_bug.cgi?id=106498
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because we register the handler separately (once for lid, once for
tablet-mode) the handler is called twice for the same event. This causes a
double-suspend of the touchpad, though it doesn't seem to have any real
effect.
Split it up so that each handler function only does one thing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And rename the model flag, no point in having separate flags here, we likely
have to add more devices over time.
https://bugs.freedesktop.org/show_bug.cgi?id=106534
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Well, I say "measure" but really at this point it just reads the
properties/axes and then does it's best to auto-generate a hwdb entry that
matches the user's hardware and sets a fuzz value on the device. Ideally this
reduces the number of hand-holding required in bugzillas. There are plenty of
things that can go wrong, so our fallback is still to throw up our hands and
point to the documentation.
https://bugs.freedesktop.org/show_bug.cgi?id=98839
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We pass the event to libinput_post_event() where it is appended to the event
queue. Except in these three cases clang doesn't seem to realize what's
happening and complains about memory leaks. I tried workarounds like
g_steal_pointer() but nothing I tried helps. So let's just pretend we're
freeing it when clang looks at us.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When finger movement exceeded the motion threshold before the finger was
recognized as a thumb, it would never be regarded as a thumb by the tap system.
This prohibited tapping until the thumb was lifted.
This is fixed by moving the check for the thumb state up such that it
happens before the motion threshold check.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than going the roundabout way of having systemd set the sensitivity
followed by us reading that udev property and hoping, just take the
sensitivity directly from sysfs. This makes us basically independent of what
systemd does (or the lack of systemd, where that is a problem).
It does remove the chance of users to trick libinput by manually adjusting the
sensitivity after the udev rules kicked in, but seriously, we should work on
fixing acceleration properly in that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We fill in the events correctly and we already allowed the
get_transformed_x/y functions on a button event, there isn't really a reason
to prohibit these.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not really an issue at this point, but some HID devices like sending
MSC_TIMESTAMP. Since we don't use them in libinput, all we do is drag
ourselves out of sleep, look at the event, frown because it's not our morning
coffee, and go back to sleep. Instead, disable the code altogether, libevdev
will mask it transparently and then the kernel will let us sleep.
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>
Too many touches are unreliable with 2+ fingers down and we should error on
the side of not detecting wobbling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we get an event other than a motion event we're not wobbling so we need to
reset and restart.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Otherwise we may detect wobble despite having a series of valid y movements,
e.g. the following sequence was detected as wobble:
x: 1 y: 0
x: 0 y: 1
x: 0 y: 2
x: 0 y: 2
x: 0 y: 1
x: -1 y: 0
x: 1 y: 0
Avoid this by resetting the history when we get a dx == 0 event. It'll take
longer for real wobble to be detected but it reduces the number of false
positives.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it possible for callers to detect whether a touch device is
single or multitouch (or even check for things like dual-touch vs real
multi-touch) and adjust the interface accordingly.
Note that this is for touch devices only, not touchpads that are just pointer
devices.
https://bugs.freedesktop.org/show_bug.cgi?id=104867
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Introduced in 416fa44d80 but there was a logic
error: we claimed to require 3 events from a trackpoint before stopping the
touchpad but the timer was only set when we actually stopped the touchpad. So
if a trackpoint sends a single event every second, we'd disable the touchpad
after 3 seconds for the duration of the timeout, then again 3 seconds later,
etc.
Fix this by always setting the timeout and resetting the event counter if no
activity happened.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This adds a third profile to the available profiles to map device-specific
speed to an acceleration factor, fully defined by the caller.
There has been a consistent call for different acceleration profiles in
libinput, but very little specifics in what actually needs to be changed.
"faster horses" and whatnot (some notable exceptions in e.g. bug 101139).
Attempts to change the actual acceleration function will likely break things
for others.
This approach opens up the profile itself to a user-specific acceleration
curve. A caller can set an acceleration curve by defining a number of points
on that curve to map input speed to an output factor. That factor is applied
to the input delta.
libinput does relatively little besides mapping the deltas to the
device-specific speed, querying the curve for that speed and applying that
factor. The curve is device-specific, the input speed is in device units/ms.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't apply any velocity diff checking on the first two events, always average
them (unless the timeout is hit or the direction changes). This averages out
some of the jumps we get on slow motion.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Two fingers on the touchpad, they're 40x40mm apart, that's a pinch. But only
after a timeout because we don't want to start a 2fg gesture if the user puts
down the third/fourth finger within the next few ms.
Related to: https://bugs.freedesktop.org/show_bug.cgi?id=99830
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a scroll wheel these mice feature trackpoint-like sticks which
generate a huge amount of scroll events that need to be handled differently
than scroll wheel events.
Signed-off-by: Peter Ganzhorn <peter.ganzhorn@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device randomly decides that a touch is now a palm, based on
the moon phase, the user's starsign and possibly what the dog had for
breakfast. Since libinput assumes that a touchpad that labels a touch as palm
has reasons to do so, let's unassume this for this device by disabling that
axis altogether and relying on the touch pressure only.
https://bugzilla.redhat.com/show_bug.cgi?id=1565692
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Semi-MT devices provide a bounding box of the fingers, and internally we don't
treat them as real MT device. Depending which finger currently provides
ABS_X/Y we may get a large jump when the other finger is released.
Basic sequence is finger 1 down, finger 2 down, finger 1 up.
On the last interaction, the ABS_X/Y which was on finger 1's coordinates now
jumps to finger 2's coordinates. This is interpreted as movement by the
tapping code, resulting in missed two-finger taps.
Ignore these movements on semi-mt devices.
https://bugs.freedesktop.org/show_bug.cgi?id=105043
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Yeah, it's duplication. But this way it's also separation and we can't
accidentally use the wrong struct.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Plenty of duplication there from the normal filter.c, but that also makes it
less likely to break if we adjust the other one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This also fixes a bug with the _noop function, because we casted to the wrong
struct the dpi value was garbage.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the standard approach for mice and touchpads to calculate the
acceleration based on the last two deltas, let's make that code shareable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's a fair bit of duplication of code from filter.c but it's not worth
disecting this and optimising it. The device is 5 years old now, we don't want
to touch this accel method so duplication is good here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
