All callers except the tap motion threshold call
tp_get_delta() followed by tp_filter_motion() - the latter normalized it
before calling into the accleration code.
Move the normalization into tp_get_delta() so we don't deal with
device-specific coordinates but normalized deltas instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Just moving some code around, no functional changes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Handle everything which is not handled by the tap, (soft)button or edge-scroll
code/statemachines in a unified way. Everything is treated as a X-finger
gesture now, and the action to take on finger movement is decided by
the gesture.finger_count setting. Pointer control now simply is seen as a
1 finger gesture, and 2fg scrolling as a 2fg gesture.
This removed the need for special-casing things like switching back to
pointer mode when lifting a finger in 2fg scrolling mode, and also lays the
groundwork for adding 3+ fg gesture support.
Note that 1 test-case needs to be updated to wait for the finger mode
switching when switching mode while a gesture has already been started.
This is actually an improvement as this stops sending spurious pointer
motion events at the end of 2fg scrolling when not lifting both fingers at
exactly the same time.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a tp_get_average_touches_delta helper function, and rename
tp_get_active_touches_delta to tp_get_combined_touches_delta to better
differentiate the two.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Not only stop 2fg scrolling, but also edge scrolling when the trackpoint
becomes active.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
With the upcoming gesture support 2fg scrolling will be handled as part of
the main gesture state machine, whereas edge scrolling has its own state
machine, our current way of dispatching scroll "actions" does not play well
with this.
Change the scroll method handling to treat edge and 2fg scrolling as 2
separate state machines. The double scroll calls this introduces will mostly
be removed when the gesture handling code lands.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't rely on a magic version tag, instead let a device define a udev rule and
drop that into the udev runtime directory before the device is created.
There are a couple of caveats with this approach: first, since this changes
system-wide state it may cause issues on the device the test suite is run on.
This can be avoided if the udev rules have filter patterns that ensure only
test devices are affected.
Second, the check test suite aborts but it doesn't run the teardown() function
if a test fails. So far this wasn't a problem since uinput devices disappear
whenever we exit. The rules files will hang around though, so an unchecked
fixture was added to delete all litest-foo.rules files before and after a test
case starts. Unchecked fixtures are run regardless of the exit status of the
test but run in the same address space - i.e. no ck_assert() usage.
Also unchecked fixtures are only run once per test-case, not once per test
function. For us, that means they're only run once per device (we use the
devices as test case), i.e. if a test fails and the udev rule isn't tidied up,
the next test may be unpredictable. This shouldn't matter too much though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The laptops on this series have the physical trackpoint buttons back but
wired them up to the touchpad instead of the trackpoint device and they appear
as BTN_0, BTN_1 and BTN_2 for left, right, middle.
The udev hwdb marks these for us with the TOUCHPAD_HAS_TRACKPOINT_BUTTONS tag
[1]. Use that tag to identify them and re-route the events through the
trackstick device after mangling the event codes to represent the actual
buttons.
[1] http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/70-touchpad.hwdb
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Allow switching between softbuttons and clickfinger on any mt-capable
clickpad.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[hdegoede@redhat.com] Keep top softbuttons working when enabling clickfinger
[hdegoede@redhat.com] Simply touchpad click method switching
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Allow the center of pinned fingers to drift over time, to avoid accidentally
unpinning fingers.
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>
Some touchpads provide touch information while the finger hovers over the
touchpad, i.e. before BTN_TOUCH. Add a touch state for those touchpads so we
can ignore the touches until they actually start.
The approach is now: instead of BEGIN we mark a new touch as HOVERING.
Use the BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP information during
tp_process_state() to mark any touches that are hovering as down or ended.
i.e. provided BTN_TOUCH is down: if BTN_TOOL_FINGER is down, one hovering
touch gets marked as down, if DOUBLETAP is down, two touches are marked as
down, etc.
When ending touches, switch them back into HOVERING if the BTN_TOOL_FINGER
is still set, otherwise end them properly.
https://bugs.freedesktop.org/show_bug.cgi?id=87197
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
BTN_TOOL_FINGER, DOUBLETAP, etc. are mutually exclusive in the kernel, so we
can use ffs here instead of manually counting.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We need this for determining hovering touches on some semi-mt touchpads.
This makes the fake_touches mask use bit 0 for BTN_TOUCH, and the other bits
for BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP, etc. BTN_TOUCH is independent of the
rest, the others are mutually exclusive in the kernel.
Since the mask isn't a straightforward bitmask anymore, abstract it all
through helper functions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Some devices require more than just flipping around the buttons, such as
tablets.
When it comes to devices like tablets, because the position of the palm rest is
on the right, the entire tablet has to be flipped around in order to be usable
by lefties. As such, this requires that we reverse the coordinates of the
tablets in addition to flipping the buttons on the tablet. As such, renaming
these functions so that they aren't specific to devices where only the buttons
are flipped seems appropriate.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For a caller to implement/provide kinetic scrolling ("inertial scrolling",
"fling scrolling"), it needs to know how the scrolling motion was implemented,
and what to expect in the future. Add this information to the pointer axis
event.
The three scroll sources we have are:
* wheels: scrolling is in discreet steps, you don't know when it ends, the
wheel will just stop sending events
* fingers: scrolling is continuous coordinate space, we know when it stops and
we can tell the caller
* continuous: scrolling is in continuous coordinate space but we may or may not
know when it stops. if scroll lock is used, the device may never technically
get out of scroll mode even if it doesn't send events at any given moment
Use case: trackpoint/trackball scroll emulation on button press
The stop event is now codified in the API documentation, so callers can use
that for kinetic scrolling. libinput does not implement kinetic scrolling
itself.
Not covered by this patch:
* The wheel event is currently defined as "typical mouse wheel step", this is
different to Qt where the step value is 1/8 of a degree. Some better
definition here may help.
* It is unclear how an absolute device would map into relative motion if the
device itself is not controlling absolute motion.
* For diagonal scrolling, the vertical/horizontal terminator events would come
in separately. The caller would have to deal with that somehow.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Original patch, before the rebase onto today's master:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Add a boolean state machine for two-finger scrolling so we know when we're
currently scrolling. If we were scrolling and it stops, pick the active
touch as pointer touch so we can go back to pointer movement without having to
lift the finger off the touchpad.
https://bugs.freedesktop.org/show_bug.cgi?id=86807
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
