A device may have ID_INPUT_JOYSTICK and ID_INPUT_KEY in which case it would
still get added, despite being a joystick device. Make sure we check only the
tablet and joystick bits - where a device has the joystick bit set but not the
tablet one we ignore it.
Note that this check will get removed in the next commit anyway, it's just
here to make tracking the change easier in the history (and figuring out where
potential regressions come from).
Fixes#415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we know that the tablet mode switch is bogus anyway, filter the event and
don't pass it to the caller. They won't know whether it's bogus so the only
result we get here is buggy behaviour.
This is the simplest solution here, it filters the mode switch at the lowest
level and thus the caller won't know that the tablet even has a mode switch at
all. Where the device doesn't have any other switches it'll also lose the
switch capability.
This may cause issues in some niche cases where the event node only has
that one bit and we now disabled it leaving us with a zero-event bit device.
Shouldn't matter to callers, but let's see.
Fixes#491
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This has never been supported through the stack. No device ever had the
required MOUSE_WHEEL_TILT_VERTICAL/HORIZONTAL udev property set, so
libinput never set the right axis source. Neither weston nor mutter
added the code for it. Even if we added wheel tilt for devices now, it
would break those devices. And the benefit we get from having those
separate is miniscule at best.
So let's do the long-term thing and just deprecate this axis source.
The wheel tilt mouse test device remains in the test suite, with the
udev properties set just to verify that we do indeed ignore those now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Take a snapshot of the time every 10 libinput_dispatch() calls. During event
processing, check if the event timestamp is more than 10ms in the past and
warn if it is. This should provide a warning to users when the compositor is
too slow to processes events but events aren't coming in fast enough to
trigger SYN_DROPPED.
Because we check the device event time against the dispatch time we may get
warnings for multiple devices on delayed processing. This is intended, it's
good to know which devices were affected.
In the test suite we need to ignore the warning though, since we compose the
events in very specific ways it's common to exceed that threshold
(particularly when calling litest_touch_move_to).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're getting too many regressions on other devices for this feature and only
ALPS touchpads need it (it's a kernel driver bug). So let's limit this to
those devices only.
For example, synaptics serial touchpads don't keep the fake fingers and slot
states in sync when going from two to three fingers, causing an erroneous slot
downgrade. See
https://gitlab.freedesktop.org/libinput/libinput/issues/434#note_419912
That interferes with this code but fixing it is hard and anyway,
synaptics touchpads don't need the slot count drop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scroll button locking is an accessibility feature. When enabled, the scroll
button does not need to be held down, the first click holds it logically down,
to be released on the second click of that same button.
This is implemented as simple event filter, so we still get the same behavior
from the emulated logical button, i.e. a physical double click results in a
single logical click of that button provided no scrolling was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Logitech MX Master 2S and 3 by default use natural scrolling
for the horizontal scroll wheel, while the main wheel
uses traditional mode. This change inverts the default
direction of horizontal scrolling.
In evdev_device_calibrate, the user matrix was not being stored when it
was the identity matrix. This resulted in
libinput_device_config_calibration_get_matrix not providing the correct
matrix. Instead of giving the identity matrix, the last non-identity
matrix set was given.
This just moves the storage of the user matrix in
evdev_device_calibrate to be above the identity matrix early return so
that it always get stored.
Signed-off-by: Brian Ashworth <bosrsf04@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our udev callout is supposed to reset the kernel fuzz to 0 and move the value
to the LIBINPUT_FUZZ property. This is to stop the kernel from applying its
own hysteresis-like approach.
Where the kernel fuzz is nonzero, something has gone wrong with that approach.
Complain about it and set our fuzz to zero, we are in the hands of the kernel
now. If we leave our fuzz as nonzero, we'll apply our own hysteresis on top of
the kernel's and that leads to unresponsive behavior.
Fixes#313
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't have a hysteresis for tablet devices, so let's leave those as-is.
This may be a slight regression in behavior compared to pre-410b157e84 now the
kernel will apply the fuzz. Let's see if anyone notices, the fuzz is usually
so tiny on tablets that it shouldn't be noticable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device looks similar to a MT device on the kernel side, but it's not a
MT device and it's not quite a tablet either. It uses slots to track up to 4
totems off the same device and the only hint that it's not a MT device is that
it sends ABS_MT_TOOL_TYPE / MT_TOOL_DIAL.
udev thinks it's a touchscreen and a tablet but we currently init those
devices as touchscreen (because all wacom tablet touch devices are udev
tablets+tochscreens). So we need a quirk to hook onto this device.
And we use a completely separate dispatch implementation, because adding the
behavior to the tablet interface requires so many exceptions that it's easier
to just add a separate dispatch interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some versions [1] of the Lenovo ThinkPad Compact USB Keyboard with TrackPoint USB
have the pointing stick on an event node that has keys but is not a regular
keyboard. Thus the stick falls through the cracks and gets disabled on tablet
mode switch. Instead of adding more hacks let's do this properly: tag the
pointing stick as external and have the code in place to deal with that.
[1] This may be caused by recent kernel changes
Fixes#291
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No real changes for the non-tablet code, but for tablets we now keep the
libwacom datbase around. The primary motivating factor here is response time
during tests - initializing the database under valgrind took longer than the
proximity timeouts and caused random test case failures when a proximity out
was triggered before we even got to process the first event.
This is unfortunately a burden on the runtime now since we keep libwacom
around whenever a tablet is connected. Not much of an impact though, I
suspect, chances are you're running a web browser and everything pales against
that anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
