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>
This is virtually the only one that matters at this point, the others may help
but they're usually more confusing than helpful.
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>
This fixes a typo in the Chromebook R13 CB5-312T hwdb name match and
extends it to the full model name, so that potential future other
Chromebook R13 devices (that are not CB5-312T) won't use these quirks.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
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>
Leftover from a previous version where printing and handling an event was
identical. Now we may handle events but not actually print them until a bit
later, so other events may have a (wrong) zero timestamp.
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 device frequently reports large pressure values during normal usage.
It does not require a tight palm threshold, because it is a desktop device
-- not built into a laptop surface -- so we can avoid false positives by
setting a very high threshold.
https://bugs.freedesktop.org/show_bug.cgi?id=105753
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>
Partial fix only because we can't guess the build dir, but at least it doesn't
complain about the missing script now. And no-one really needs to run this
anyway.
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>
This is generated by the kernel's autorepeat code, see input_repeat_key() in
drivers/input/input.c
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The touch size threshold was too high, so occasionally libinput would
think the finger had lifted when it hadn't and events would be ignored.
Similarly, the palm threshold was too low, so occasionally libinput would
think a heavy single finger was a palm and ignored that too.
This fixes both of those issues.
https://bugs.freedesktop.org/show_bug.cgi?id=103572
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>
