Use TOUCHPAD_MIN_SAMPLES in tp_get_delta rather then hardcoding "4".
Also remove the superfluous TOUCHPAD_MIN_SAMPLES check before calling
tp_get_delta in tp_get_pointer_delta, this is not necessary as tp_get_delta
already checks itself.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When clicking a clickpad the user may want to switch fingers to move the
pointer around, without lifting so as to not release the button.
Switch to using combined motion of all touches when a clickpad is clicked to
allow this.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86807
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Split out the pointer-motion handling into a helper function.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We use 2 mechanisms to unregister the trackpoint event listener depending on
device removal order.
1) We have a device_removed callback, if the trackpoint gets removed before
the touchpad, this gets called, sees the device being removed is the trackpoint
and unregisters the listener
2) If the touchpad gets removed first, then in tp_destroy we unregister the
listener
2) May be delayed beyond the destruction of the trackpoint itself if the
libinput user has a reference to the libinput_device for the touchpad.
When this happens the trackpoint still has an eventlistener at destroy time
and an assert triggers.
To fix this we must do 2) at the same time as we do 1), so at remove time.
While working on this I noticed that the touchpad code was also cancelling
timers at destroy time rather then remove time, which means that they may
expire between remove and destroy time, and cause events to be emitted from
a removed device, so this commit moves the cancelling of the timers to the
remove callback as well.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Some dispatchers may want to do some cleanup at remove time, rather then at
destroy time.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
For certain applications (such as FPS games) it is necessary to use
unaccelerated motion events (the motion vector that is passed to the
acceleration filter) to get a more natural feeling. Supply this
information by passing both accelerated and unaccelerated motion
vectors to the existing motion event.
Note that the unaccelerated motion event is not equivalent to 'raw'
events as read from devices.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
400 used to be the default DPI for many mice but it it's not anymore. A survey
of mice shows that 400 is still common as one of the pre-configured settings
in switchable multi-resolution gaming mice, but devices with a single
resolution mostly favor 1000 dpi.
Let's make that switch now so that any future changes to the pointer
acceleration code assumes that resolution as a default.
For the touchpad, this has a bad side-effect, caused by our expectation of
mouse vs touchpad behaviours: our acceleration code ignores device type and
provides the same acceleration for the same physical movement. Unfortunately,
we expect touchpads to be significantly slower than mice.
The previous 400 DPI worked because it caused an acceptable slowdown on input.
e.g. on the T440 with a res of 42 units/mm, the scale coefficient was 0.37.
For 1000 DPI as default, this now results in 0.94, i.e. speeding up the
touchpad by a factor of 2.5. That is way too fast.
Adding touchpad-specific filter code is a bigger project, so let's just add a
fixme for now and scale the coefficient back to what it was before the
DPI default change. Effect: touchpad behaves as before.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The filter code is what relies on some default dpi configuration to apply
pointer acceleration and expects the input coordinates to be pre-scaled to
that resolution.
Let's move the define here so we can use it from the touchpad code too.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Add edge-scrolling support for non multi-touch touchpads as well as for
users who prefer edge-scrolling (as long as they don't have a clickpad).
Note the percentage to use of the width / height as scroll-edge differs from
one manufacturer to the next, the various per model percentages were taken
from xf86-input-synaptics.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=85635
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is useful to know in some cases, it is e.g. necessary to figure out
which percentage of a touchpads range to use as edge for edge-scrolling.
Note this is a slightly cleaned up copy of the same code in
xf86-input-synaptics.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is purely a code move, this is a preparation patch for adding edge
scrolling support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're about to add natural scroll support to other devices as well, let's
share the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Default to 2fg scrolling for now, once we have edge-scrolling we can default
to edge-scrolling on touchpads which cannot detect more than 1 touch.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
To avoid confusion with scroll mode configuration.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No effect, we're just initializing with the same value we did before. What is
important here is the comment, the touchpad scroll threshold is in mm
for touchpads providing a resolution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The touchpad tap code explicitly supports 2 finger tap-n-drag, this commit
adds a test-case for this, which fails due to the 2 finger scrolling code
sending scroll events during a 2 finger tap-n-drag.
And this commit fixes the test-case, by not sending scroll events while a
tap-n-drag is active.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
In the future, we should allow multiple sendevent modes set simultanously.
Change the API to use a bitmask instead of a single return value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Some laptops with both a clickpad and a trackpoint have such a large touchpad,
that parts of the users hands will touch the pad when using the trackpoint.
Examples of this are the Lenovo T440s and the Toshiba Tecra Z40-A.
This commit makes libinput automatically disable the touchpad while using
the trackpoint on these devices, except for the buttons, as people may want
to use the touchpad (hardware or soft) buttons while using the trackpoint.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is what the return value in tp_tap_handle_state is called, and it better
reflects what the flag does.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tapping and clickfinger is unaffected, physical and software buttons are
swapped. The main area of a clickpad remains as left button though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We don't need a separate filter struct, we can use the parent evdev device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We ran a userstudy, evaluating three different accel methods. Detailed results are
available at:
http://www.who-t.net/publications/hutterer2014_libinput_ptraccel_study.pdf
We found that there was little difference between the method we had in
libinput 0.6 and this three-line function. Users didn't really notice a
difference, but measured data suggests that it has slight advantages in some
use-cases.
The method proposed here is the one labeled "linear" in the paper, its profile
looks roughly like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
Differences to the previous accel function:
- both inclines are linear rather than curved
- the second incline is less steep than the current method
From a maintainer's point-of-view, this function is significantly easier to
understand and manipulate than the previous one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Make it easier to hit the topbutton area when the touchpad is disabled,
normally we don't want to make the topbutton area too big, so as to not
interfere with normal touchpad operation, but when disabled we have no such
worries.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On a TOPBUTTONPAD, we can't disable the touchpad altogether - the trackstick
relies on the touchpad's top software buttons.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For touchpads with top softbuttons we don't want to fully disable the touchpad
on suspend, as we want to keep the top softbuttons working for the trackpoint.
So in the suspended state some of the touchpad sub-statemachines will keep
running (e.g. buttons) where others (e.g. tap) will not. This means that
we will need to clear the touchpad state on resume too, to avoid things
being in an inconsistent state after resume.
This commit factors out the state clearing code into a helper functions, so
that the same code can be used on resume.
No functional changes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The touchpad top softbuttons such as found on the Lenove T440 are intended for
use with the trackstick. Route their events through the trackstick, so that
they can be used for e.g. middle button scrolling with the trackstick.
Note that sending top button events to a disabled trackpoint makes no sense
(and will mess up internal state). Likely a user with a disabled trackpoint
will still expect the top buttons to work, so rather than not sending events
in that case, simply treat a suspendeded trackpoint as not being there, and
send the events directly from the touchpad device.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The top soft buttons are intended for use with a trackpoint, and to e.g.
make middle button scrolling work correctly, we must post the events for
these "buttons" through the trackpoint device.
This commit is a preparation patch for this, it adds a link to the
trackpoint to the touchpad, but does not yet do anything with it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have the ability for a device to form a link to another device through the
device_added / device_removed callbacks. A device having such a link to
another device may also want to know when that other device is disabled /
enabled (suspended / resumed). So add a notification mechanism for this too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
So that it can be used for middle button trackpoint scrolling too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For conditional touchpad disabling we need two pieces of knowledge: is the
device an internal touchpad and is another device an external mouse-like
device. For that use-case it's enough to tag any device that's on USB and
Bluetooth with pointer capabilities as external mouse. A more complex can be
done when needed.
The tag function is part of the dispatch interface (to save on udev code) and
called before the caller is notified about the new device, i.e. the device is
fully configured by the time it needs to be tagged, and other devices can rely
on the tags being assigned by the time they get notified about the new device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When a device is added or removed, notify all internal devices about the
device change. This allows all devices to configure themselves depending on
other devices in the system. Prime use-case here is an internal touchpad that
wants to know if an external mouse is connected.
On device added, notification goes both ways: existing devices are notified
about the new device, and the new device is notified about existing devices.
On device removed, notification only goes one way.
In both cases, the internal notification is complete before the event is sent
to the caller.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We may be in the middle of a software button click or a tap, so make sure we
go back to the device-neutral state by unwinding.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
It's up to a evdev device backend to configure seat capabilities it
supports. Even though it may be possible for a touchpad to have extra
keys, there is currently no support for sending keyboard events from the
touchpad driver, and if that would be implemented, it'd be a detail of
the touchpad driver, not the generic evdev device part.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
On semi-mt touchpads the reported position of the first finger down may
jump when the pad switches from st to mt mode. When this happens a large
delta gets seen on the first finger at the same time the second fingers
is first seen down, causing a spurious 2 finger scroll event.
Reset the motion history when nfingers changes on semi-mt pads to avoid this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Force a cast of the input arguments to a double before the divide, rather
than after the divide.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Multi-touch pads may track less touches then they can report fingers being
present through BTN_TOOL_FOO. So create fake touches for fingers reported
by BTN_TOOL_FOO on multi-touch pads too (when necessary).
This fixes e.g. 3 finger tap not working on the T440s.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't process fake touches, e.g. re-adding the same position to the motion
history when they are not dirty. This could trigger for example on a button
press.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They were already protected against being called twice between SYN_REPORT, but not
for being called twice before a SYN_REPORT arrives.
This allows simplifying tp_process_fake_touch a bit. Note while at it also
also flip the if condition in tp_process_fake_touch so that the if is
true when the finger is down, and remove the bogus t->state = TOUCH_NONE.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They don't set resolution so we can't calculate the size but we know they're
big enough to need palm detection.
And fix the descriptor for the bcm5974. For some reason this was advertising
synaptics coordinates. Fix it to represent (one of) the apple touchpads.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On small touchpads, a touch that intends to go across the width of the
touchpad is likely to start in the edge zone. Likewise, on those touchpads the
chances of a palm event happening on the edge is small.
A minimum width of 8cm determined by an elaborate process of completely
unscientific guesswork: the x220 is roughly 7.5cm across and doesn't suffer
much from edge events, the T440s is 10cm across and definitely suffers from
it. So the trigger width likely somewhere in between which makes 8cm about as
valid as any other guess.
Note that this disables palm detection for resolution-less touchpads too - if
we don't know how big the touchpad is we can't know if palm detection on the
edges is necessary.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Any legitimate finger movement that starts in the palm area is expected to
move out of the palm area at an angle roughly orthogonal to the edge of the
touchpad. Check for the direction of the movement vector, and if it is within
the accepted cardinal/ordinal directions then proceed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
