Devices tagged as accelerometers may also be other devices like tablet pads.
Only ignore pure accelerometer devices but disable the accelerometer axes for
devices that have multiple types.
https://bugs.freedesktop.org/show_bug.cgi?id=102100
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
The current tests worked because all rings had the same range, so our error
margin covered for that. With the upcoming MobileStudio Pro 16 pad device, the
range is half and our error margins don't work anymore. Switch to a more
reliable approach that tests every integer value the wheel can send, even
though it relies on kernel filtering.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The recommended way to have libinput ignore specific devices so far was to
remove the ID_INPUT* properties from the device. That may also affect other
pieces of the stack that need access to this device.
For the niche case of a device that should only be ignored by libinput but
otherwise be treated normally by the system, we now support the
LIBINPUT_IGNORE_DEVICE property.
If the property is set to "0", it's equivalent to being unset. This gets
around some technical limitations in udev where unsetting a property is
impossible via a hwdb entry.
https://bugs.freedesktop.org/show_bug.cgi?id=102229
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And make it init the full litest device minus the libinput device. This
enables us to add litest devices that aren't handled by libinput.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
"This gives some more sensitivity to the fingers without introducing spurious
touches and movements."
https://bugs.freedesktop.org/show_bug.cgi?id=101670
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It seems the unit tests rely on another part of <linux/input.h> which I
missed in the previous commit (5cf4b35b).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Various files use #include <linux/input.h> and, if the system input.h is
too old, will fail to compile. Use the internal copy by adding -Iinclude
to the build command lines. This was the case in the old autotools build
system.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On MBP13,3 the touch areas are quite large, and a thumb size easily gets
to 1000+. Hence need to be able to set palm sizes > 1024 (using 1200
currently).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Bluetooth wreaks havoc with the timestamp of the input events coming
from the touchpad, enable timestamp smoothing support to counter this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some devices, specifically some bluetooth touchpads generate quite
unreliable timestamps for their events. The problem seems to be that
(some of) these touchpads sample at aprox 90 Hz, but the bluetooth stack
only communicates about every 30 ms (*) and then sends mutiple HID input
reports in one batch.
This results in 2-4 packets / SYNs every 30 ms. With timestamps really
close together. The finger coordinate deltas in these packets change by
aprox. the same amount between each packet when moving a finger at
constant speed. But the time deltas are e.g. 28 ms, 1 ms, 1 ms resulting
in calculate_tracker_velocity returning vastly different speeds for the
1st and 2nd packet, which in turn results in very "jerky" mouse pointer
movement.
*) Maybe it is waiting for a transmit time slot or some such.
This commit adds support for a real simple timestamp smoothing algorithm,
intended *only* for use with touchpads. Since touchpads will send a
contineous stream of events at their sample rate when a finger is down,
this filter simply assumes that any events which are under
event_delta_smooth_threshold us apart are part of a smooth continuous
stream of events with each event being event_delta_smooth_value us apart.
Theoritically a very still finger may send the exact same coordinates
and pressure twice, but even if this happens that is not a problem because
a still finger generates coordinates changes below the hyst treshold so
we ignore it anyways.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't know the position of the third finger on 2-slot touchpads, differing
between swipe and pinch is reliable. Simply disable 3-finger pinch and always
use swipe; 3fg pinch is uncommon anyway and it's better to have one of the
gestures working reliably than both unreliably.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The lid dispatch interface is a one-trick pony and can only handle SW_LID. It
ignores other switches but crashes on any event type other than EV_SW and
EV_SYN. Disable those types so we just ignore the event instead of asserting.
https://bugs.freedesktop.org/show_bug.cgi?id=101853
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Some devices have worn-out switches or just cheap switches that trigger
multiple button events for each press. These can be identified by unfeasably
short time deltas between the release and the next press event. In the
recordings I've seen so far, that timeout is 8ms.
We have a two-stage behavior: by default, we do not delay any events but we
monitor timestamps. The first time a bouncing button is detected we switch to
debounce mode. From then on, release events are delayed slightly to check for
subsequent button events. If one occurs, the releas and press are filtered. If
none occurs, the release event is passed to the caller.
https://bugs.freedesktop.org/show_bug.cgi?id=100057
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a timer_func causes the removal or addition of a different timer, our tmp
pointer from the list_for_each_safe may not be valid anymore.
This was triggered by having the debounce code trigger a middle button state
change, which caused that timer to be cancelled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Race conditions may happen where code that cancels a timer is called just
as that timer triggers. If we cancel a timer, we assume that we've put the
code into a state where the timer firing will trigger a bug.
This could be observed with the middle button code if the release event was
held back just long enough. The button release code cancelled the timer, set
the state back to idle and then complained when the timeout handling sent a
'timeout' event while being in idle.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the kernel sends us a button press for a button that is thought to be down
we have lost track of the state of the button. Ignore the button press event,
in the hope that the next release makes things right again.
A release event may be masked if another process grabs the device for some
period of time, e.g. libinput debug-events --grab.
https://bugs.freedesktop.org/show_bug.cgi?id=101796
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add parsing for a LIBINPUT_ATTR_TRACKPOINT_RANGE property to enable
hardware-dependent ranges. These take precedence over the sensitivity parsing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was to counteract hardware that doesn't work well out of the box,
resulting in quite different behavior across devices. Specifically, only
some trackpoints even have the sensitivity setting.
Change to take over all of the pointer acceleration on trackpoints, so we can
control the actual behavior mostly independent of the system setting. So we
drop the CONST_ACCEL parsing (which never was handled as const accel anyway)
and undo the effect that the SENSITIVITY udev property has. [1]
We take a default range at the default sensitivity and multiply it by the
proportion of the current sensitivity. This seems to be accurate enough.
[1] In the future, we should read not only the property but also the sysfs file to
make sure we're handling the right value, but for now this will do.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Switch to a pure factor with a max scaled after a function. The offset is just
0 now (will be removed eventually). Both are determined with a function based
on a linear/exponential regression of a sample set of data pairs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Trackpoints can send very different ranges between the various pressures.
Collect the data and print it out to get an idea of what ranges are realistic.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no guarantee that libinput does the right thing if memory allocation
fails and it's such a niche case on the systems we're targeting that it just
doesn't matter. Simply abort if zalloc ever fails.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
doxygen ends the @bug command when a new section command (@code) is
encountered, leaving us with an "Example code:" on the Bug List page.
Add an empty line to cut off here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Apple touchpads don't use ABS_MT_PRESSURE but they are multitouch touchpads,
so the current pressure-based handling code doesn't apply because it expects
slot-based pressure for mt touchpads.
Apple does however send useful data for ABS_MT_WIDTH_MAJOR/MINOR, so let's use
that instead. The data provided in those is more-or-less random, so we need a
hwdb entry to track the acceptable thresholds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The max values on ABS_MT_TOUCH_MAJOR/MINOR aren't hard limits, they basically
represent the size of a finger with (afaict) a suggestion that anything
greater than the max may be a palm. Disable the 0-100% range checks for those
axes so we can send custom events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the keyboard is removed while dwt thinks it is in active state, that state
is never reset and subsequent touches are ignored.
https://bugs.freedesktop.org/show_bug.cgi?id=101743
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This isn't currently hooked up to the fdo repo but it's hooked up to my
github mirror. I had SemaphoreCI hooked up to that before but it only
supports ubuntu 14.04 and the recent meson switch made it a bit hard to setup.
CircleCI supports running docker containers, so let's do that and run against
the most recent released Fedora and a recent Ubuntu. I'm not bothering with
rawhide, it's likely to increase the work for little gain when it's in a
semi-broken state.
Run the default build with a few permutations to test meson options. Run
scan-build too but that's just for the logs, eventually this may turn into a
hard failure.
Ubuntu 17.04's meson is too old, so we have to clone that from git. Install
arguments are taken from the meson.deb package.
Most of this effort was done by Benjamin Tissoires.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Cc: Benjamin Tissoires <benjamin.tissoires@gmail.com>
