We used to mark dell touchpads this way but let's make this more generic.
Nothing else used the dell touchpad model flag, so we can simply replace it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is added on top of the click angle handling, so the actual axis values
simply fall back onto whatever is set by udev, including the default fallbacks
to 15 and whatnot.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Only allow values of 0 and 1 for udev flags. Not that I'm aware of anyone
using anything else (i.e. his shouldn't break anything) but it's best to be as
restrictive as possible here.
Bonus effect: it's now possible to unset LIBINPUT_MODEL_* tags as well,
previously any value (including 0) was counted as "yes".
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This touchpad has cursor jumps for 2-finger scrolling that also affects the
single-finger emulation. So disable any multitouch bits on this device and
disallow the 2-finger scroll method. This still allows for 2-finger
tapping/clicking.
https://bugs.freedesktop.org/show_bug.cgi?id=91135
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Move the code from the touchpad code into the more generic evdev code
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Avoids parsing issues when we're in different locales
https://bugs.freedesktop.org/show_bug.cgi?id=98828
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Announces 4 slots but only sends data for the first two. This causes libinput
to miss three-finger actions (we don't look at BTN_TOOL_TRIPLETAP if we have
3 or more slots).
https://bugs.freedesktop.org/show_bug.cgi?id=98100
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Not all mice have a click angle with integer degrees. The new
MOUSE_WHEEL_CLICK_COUNT property specifies how many clicks per full rotation,
the angle can be calculated from that.
See https://github.com/systemd/systemd/pull/4440 for more information
CLICK_COUNT overrides CLICK_ANGLE, so we check for the former first and then
fall back to the angle if need be. No changes to the user-facing API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Same as the HP Compat 8510, it doesn't send BTN_TOOL_DOUBLETAP/TRIPLETAP. This
may be a general issue with those series but they're 6 years old now, so
it's questionable to spend extra effort detecting them.
https://bugs.freedesktop.org/show_bug.cgi?id=98538
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A joystick has ID_INPUT_JOYSTICK *and* ID_INPUT set, so we need to check for
both.
https://bugs.freedesktop.org/show_bug.cgi?id=98009
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
INPUT_PROP_BUTTONPAD is not set on this device and RMI4 which should fix this
is a bit too far into the future at this point. Hack around it.
https://bugs.freedesktop.org/show_bug.cgi?id=97147
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
So far we've relied on the wacom kernel module to do touch arbitration for us
but that won't be the case in upcoming kernels. Implement touch arbitration in
userspace by pairing the two devices and suspending the touch device whenever
a tool comes into proximity.
In the future more sophisticated arbitration can be done (e.g. only touches
which are close to the pen) but let's burn that bridge when we have to cross
it.
Note that touch arbitration is "device suspend light", i.e. we leave the
device enabled and the fd is active. Tablet interactions are comparatively
short-lived, so closing the fd and asking logind for a new one every time the
pen changes proximity is suboptimal. Instead, we just keep a boolean around
and discard all events while it is set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Previously suspending a touch device with at least one touch down would never
release the touch point.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
If the touch is inactive the seat_slot is -1 and we filter the event. The same
happens for devices that send may touch events but aren't touch devices like
any touch-capable mouse. In those cases we sent a bunch of 'empty' touch frame
events. Stop this by checking if we actually flushed the respective event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Rather than testing before if we have an event that matches the need for a
frame simply return the event sent by the flush function. If that event
matches those that need frame events, send the event then.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
No functional changes, this is prep work for being able to release touch
points on the fly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
The touchpad's says it can do two- and three-finger detection but it never
sends events for it. Disable them so we treat it as pure single-finger
touchpad.
https://bugzilla.redhat.com/show_bug.cgi?id=1351285
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Introduced in b02acd346b, we need to check the angle returned by the parsing
function, not the variable passed in.
Found by Coverity
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We leave the old LIBINPUT_MODEL_TRACKBALL in place until we can rely on
systems to have the new systemd tagging.
https://github.com/systemd/systemd/pull/3872
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The Logitech MX master has different click angles for the two wheels.
https://github.com/systemd/systemd/issues/3947
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The only places we should typecast from device->dispatch is where we have
external entry points. Everywhere else keep the pointer to the dispatch
interface we already have anyway.
This way we avoid papering over a potential re-use of a function from
non-evdev code, passing in the wrong dispatch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is only used by the fallback dispatch method, not by any of the others.
Anything dispatch-specific should go into that struct.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than setting a magic device field and returning true/false just return
the dispatch method.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All these effectively returned bools anyway, switch the signature over to be
less ambiguous.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
These are internal functions, if we need them to return an error code we can
change that at any time. Meanwhile, if we only ever return 0 anyway we might
as well just make them voids to save on error paths.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
All Dell touchpas appear to have a visual marker on their touchpads. With a
visible marker our middle button can (and should) be much smaller since we
can rely on users to hit the button precisely.
https://bugs.freedesktop.org/show_bug.cgi?id=96710
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
To unify this we need to move the tagging process forward so tp_init() can
rely on it for config setup. This means moving it to the touchpad init code.
Other than that no real functional changes, the rules stay the same:
* serial/i2c/etc. are considered internal touchpads
* Bluetooth is always external
* USB is external for Logitech devices
* USB is external for Wacom devices
* USB is internal for Apple touchpads
And if we can't figure it out, we assume it's external and log a message so we
can put a quirk in place.
https://bugs.freedesktop.org/show_bug.cgi?id=96735
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
