Prefix device log messages with the device's sysname so it's more obvious
where the messages are coming from. This makes it much easier to grep for a
specific device's messages but also adds some identifier to messages that
were previously without any identifier (e.g. all the state machine debugging)
All info and error messages also automatically prefix the device name, so
those messages are standardised too, e.g
an info message now:
event4 - SynPS/2 Synaptics TouchPad: is tagged by udev as: Touchpad
a debug message now:
event4 - using pressure-based touch detection
And since this required changing a lot of the strings in messages anyway,
polish a few minor things too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Before, our states were idle, button down and scrolling. This adds a state
where the button is down and the timeout has expired (i.e. we're ready to send
scroll events) but we haven't actually sent any events anymore.
If the button is released in this state, we generate a normal click event.
https://bugs.freedesktop.org/show_bug.cgi?id=99666
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes, preparation work for adding another state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Device needs BTN_MIDDLE disabled, this way middle button emulation is present
by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We don't initialize click methods on devices with physical buttons. This model
is a special case, it's not a clickpad but it only has one button (because one
button is all you ever need and whatnot).
https://bugs.freedesktop.org/show_bug.cgi?id=99283
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Set the dispatch type on creation, then check that whenever we try to get the
dispatch struct. This avoids a potential mismatch between the backends.
Plus, use of container_of means we're not dependent on the exact layout
anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Create a lid_switch_interface to handle lid switch events, so the touchpad can
be disabled when lid is closed.
Signed-off-by: James Ye <jye836@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
center + diff is the input coordinate. Simplify the code so it's clear what
we're returning. And document the function to explain what it does.
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>
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>
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>
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>
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>
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>
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>
Expose the middle button emulation on software buttons as proper config
option. When enabled, remove the middle button software button area.
https://bugs.freedesktop.org/show_bug.cgi?id=96663
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Until the kernel patches to handle LED group switching are in place we provide
the external API backed by an implementation that simply exposes one group
with one mode and no toggle buttons. This allows us to ship a libinput release
with the API in place and switch libinput later without having all the stack
above us being delayed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
The removal of the hysteresis even on precise touchpads has led to
difficulties controlling the cursor in a few instances. Since 27078b2667
we only have the hysteresis on Apple touchpads and the Lenovo *40 series and
later. Even on those do we see some positioning difficulties (bug 94379).
So restore the hysteresis by default again for all touchpads. In the future a
knob could be exposed for precision vs reactivity or something, but for now
the drawback of imprecise positioning does not outweigh the benefits we get
on those few devices.
https://bugs.freedesktop.org/show_bug.cgi?id=94379
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This device has a touchpad on the mouse but it's labeled as mouse. For litest
we only label it as LITEST_MOUSE feature and test the touchpad directly on the
device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And change the various callers, especially those where we only had the
separate struct for indentation purposes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A large part of the bugs seen right now are related to touchpads jittering too
much. Fixing them one by one is entertaining, but time consuming. Right now
the number of touchpads that require a hysteresis seem to outnumber those that
don't, so switch the approach around: leave the hysteresis in place but
disable it for those touchpads that don't need it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Was only used for the touchpad hysteresis, we can re-use the wobbly touchpad
tag for this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Trackballs are effectively stationary devices and can be positioned at any
rotation. They are also employed by users with impaired dexterity which
sometimes implies that they are positioned at an non-default angle to make the
buttons easier to reach.
Add a config option for rotation for trackball devices. Currently only
supported for 90-degree angles, if there is a need we can add more angles
later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>