All "goto err" resides after fd have been properly initialized.
Fixes "Comparison is always true because fd >= 0." warning by LGTM.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
When using button scrolling, a hardcoded delay of 200 milliseconds between
button down and scroll events being emitted makes fast scrolling gestures feel
clunky and sometimes fail entirely. This feature comes from
xf86-input-mouse, was copied into xf86-input-evdev and reimplemented in
libinput.
This was, as far as can be determined, to allow right clicks without
triggering scrolling. libinput now also has distance triggers (2bbf4a0117)
and sends button events if no movement has happened for long clicks,
regardless of the delay.
The 200ms delay is thus not really necessary anymore, let's drop it to 38ms
which is just above the 3-event threshold for 8/10/12ms intervals which is
most devices.
Fixes#237
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On the Asus Vivobook Flip 14, the tablet mode switch is unreliable and always
on. Instead of marking every device as 'do not suspend', just mark the tablet
switch itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a middle-button-emulating device is removed with one button down, the timer
never gets cancelled and triggers an assert during device removal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device was removed while a button was held down and within the timeout,
the timer was never cancelled (and removed from the timer list), triggering an
assert during device removal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It's missing INPUT_PROP_BUTTONPAD but working kernel drivers prove to be
elusive. Meanwhile, add a quirk here that force-enables this bit.
Fixes#177
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a more flexible approach than adding a model flag and the C code to
just call libevdev_disable_event_code(). There's a risk users will think this
is is a configuration API but there are some devices out there (e.g. the
Microsoft Sculpt mouse) that need a more generic solution.
Case in point: the Sculpt mouse insists on holding BTN_SIDE down at all times.
We cannot ship any quirks for that device because we only have the receiver's
generic VID/PID. So a local override is required, but we might as well make
that one generic enough to catch other devices too in the future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Log if we use a non-default click angle setting, makes it easier to debug
this. The condition to add the log was a bit unwieldly to read, so this also
factors out the property names to temporary variables.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This touchpad stops sending pressure data after the first frame of the second
finger down. If the initial pressure is too light, the finger doesn't get
detected even when the pressure increases in the future.
This thing is from 2014, so let's just disable the pressure axes on it
and skip the pressure-based touch detection code. Let's hope that it doesn't
also have ghost touches on light interactions...
Fixes#145
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Anything that merely requires a once-off check during initialization can just
use the quirks directly, no need to copy them over to the model flags.
Fixes#146
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On Dell i2c touchpads, the controller appears to go to sleep after about 1s of
inactivity on the touchpad. The wakeup takes a while so on the next touch, we
may see a pointer jump, specifially on the third event (i.e. touch down,
event, event+jump). The MSC_TIMESTAMP value carries a hint for what's
happening here, the event sequence for a touchpad with scanout intervals
7300µs is:
...
MSC_TIMESTAMP 0
SYN_REPORT
...
MSC_TIMESTAMP 7300
SYN_REPORT +2ms
...
MSC_TIMESTAMP 123456
SYN_REPORT +7ms
...
MSC_TIMESTAMP 123456+7300
SYN_REPORT +8ms
Note how the SYN_REPORT timestamps don't reflect the MSC_TIMESTAMPS.
This patch adds a quirk activate MSC_TIMESTAMP watching. When we do so, we
monitor for a 0 MSC_TIMESTAMP. Let's assume that the first event after that is
the interval, then check the third event. If that third event's timestamp is too
large rewrite the touches' motion history to reflect the correct timestamps,
i.e. instead of the SYN_REPORT timestamps the motion history now uses
"third-event SYN_REPORT timestamps minus MSC_TIMESTAMP values".
The pointer accel filter code uses absolute timestamps (#123) so we have to
restart the pointer acceleration filter when we detect this jump. This allows
us to reset the 0 time for the filter to the previous event's MSC_TIMESTAMP
time, so that our new large delta has the correct time delta too. This
calculates the acceleration correctly for that window.
The result is that the pointer is still delayed by the wake-up window (not
fixable in libinput) but at least it ends up where it should've.
There are a few side-effects: thumb, gesture, and hysteresis all still use the
unmodified SYN_REPORT time. There is a potential for false detection of either
of these now, but we'll have to fix those as they come up.
Fixes#36
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This function expected distances per-frame, not per-time which gives us
different behaviors depending on the hardware scanout rate. Fix this by
normalizing to a 12ms frame rate which reflects the touchpad I measured all
the existing thresholds on.
This is a bit of a problem for the test suite which doesn't use proper
intervals and the change to do so is rather invasive. So for now we set the
interval for test devices to whatever the time delta is so we can test the
jumps without having to worry about intervals.
Fixes#121
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput applies averaging to the velocity of most pointer devices. Averaging
the velocity makes the motion look smooth and may be of benefit to bad input
devices. For good devices, however, it comes at the unfortunate price of
decreased accuaracy.
This change turns velocity averaging off by default (sets ntrackers to 2 instead
of 16) and allows for it to be turned back on via a quirk, for bad devices which
require it.
Measuring the trackpoint range has not shown to be sufficient or precise
enough to be used as an ingredient for trackpoint acceleration. So let's just
switch back to a generic multiplier that we can apply to the input deltas do
undo any device-specific lack of scaling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The lenovo compact keyboard with trackpoint has a sensitivity of 5, which
causes the trackpoint range to be 0. This in turn causes inf/NaN during
pointer acceleration as we divide by 0 and makes the cursor go unpredictably
somewhere it probably shouldn't be.
This is part of a wider problem in that the current sensitivity handling
doesn't work well for values well below the default of 128. Any such values
are scaled up to multiples of pixels instead of just working as-is.
Reverting the automatic sensitivity parsing, any systemd udev property set to
change the sensitivity increases it, so we don't run into this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1583324
This reverts commit a4036a33ca.
This looked good on paper but clearly no-one (including myself) ever tested this
in a real-life situation or they would've noticed that the constant factor is
missing, causing a segfault on the first two-finger scroll event, touchpad
gesture or button scrolling.
Adding the constant factor makes the API much worse and the benefit is
unclear, so out of the window it goes. We can revisit this for libinput 1.12
but this isn't going to make the next release.
This reverts commit d8bd650540.
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>
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>
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>
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>
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>
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>
When the X1 Yoga is in tablet mode, one capacitative touch button (windows
key, sends KEY_LEFTMETA) and two side volume buttons are accessible on the
front. The key event comes through the internal keyboard that we disabled in
tablet mode so it stops working.
Luckily the Yoga physically disables the "main" keyboard when in tablet mode,
so all we have to do is skip our code to disable the keyboard and the keys are
working again.
https://bugs.freedesktop.org/show_bug.cgi?id=103749
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is an external keyboard+touchpad but not recognised as touchpad by the
kernel so it's in mouse emulation mode. Double-taps are sent with impossibly
close timestamps and filtered out by the debouncing code. Since this isn't a
real button that can wear out anyway, let's just disable debouncing on this
device.
https://bugs.freedesktop.org/show_bug.cgi?id=105974
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we get to this point, we've already ruled out invalid arguments and this
shouldn't really fail, so let's reply with UNSUPPORTED instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The kernel fuzz handling is buggy, especially when we want to rely on the fuzz
value for our hysteresis. But since this is a hw property and (at least
sometimes) set by the driver, we can't make this a pure libinput hwdb set
either.
So our workaround is:
* extract the (non-zero) fuzz into a udev property so we don't lose it
* set the fuzz to 0 to disable the in-kernel hysteresis
* overwrite our internal absinfo with the property fuzz
This way we get to use the hw-specified fuzz without having the kernel muck
around with it. We also get to use the EVDEV_ABS_ values in 60-evdev.hwdb to
override a driver-set fuzz.
Two drawbacks:
- we're resetting the kernel fuzz to 0, this affects any other users of the
device node. That's probably a minor impact only.
- we can only save this in a udev property there's a risk of this information
getting lost when playing around with udev rules. That too should be a minor
issue.
https://bugs.freedesktop.org/show_bug.cgi?id=105303
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
