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>
Two separate flags needed, want_left_handed and left_handed to avoid switching
to left_handed while a button is still down. Since each backend has a
different way of determining whether buttons are down, let them set a function
to do exactly that. Then call that function whenever a button release event is
posted to switch the device to right/left-handed if applicable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For some tests we need to string multiple event sequences together into one
event frame. Use a push/pop frame approach that stops litest from sending any
EV_SYN/SYN_REPORT events, so we can merge two touches together by e.g.
litest_push_event_frame(d);
litest_touch_down(d, 0, 10, 10);
litest_touch_down(d, 1, 20, 50);
litest_pop_event_frame(d);
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Rather than a random msleep() with a comment, use a helper function that
describes what we're waiting for. Also makes changing the timeouts easier in
the future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2-finger scrolling only, we don't have anything else yet
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Natural scrolling is simply inverted scrolling, but I decided to
use the Apple terminology simply because it's easier to google for.
Add the usual quartett of config options for has/set/get/get_default/, as a
boolean option rather than an enum for scroll mode to avoid name collusion
with the (currently in the works) edge scrolling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Hard-coded to 50 devices, because for a debugging tool that's plenty.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Only exposes one knob - speed, normalized to a [-1, 1] range with 0 being the
neutral "this is what we think is normal" speed. -1 and 1 reflect the
slowest/fastest reasonable speed on this device.
Note: with this API we commit to having any pointer accelerating as a true
gliding scale. We cannot map the [-1,1] range into a discrete set of steps
as we do not communicate to the caller whether a specific value has changed
the acceleration. Without that, a caller may assume that acceleration has
changed even when it is not visible to the user.
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>
The acceleration curve consists of four parts, in ascii-art 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.
This patch adjusts the curve based on a [-1, 1] range. For anything below 0,
the plateau is longer (i.e. accel kicks in at a higher speed), the second
incline is flatter (i.e. accel kicks in slower) and the max accel factor is
lower (i.e. maximum speed is slower). For anything above 0, the inverse is
true, acceleration kicks in earlier, harder and is faster in general. So the
default/min/max curves overlaid look something like this:
________ max
| _______ default
| / _____ min
_|_/_/
/
/
Note that there's a limit to what ascii art can do...
Note that there are additional tweaks we can introduce later, such as
decreaseing the unaccelerated speed of the device (i.e. lowering the first
plateau).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes, prep work for the config interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
To keep the implementation of a filter separate from the users of a filter.
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>
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>
Make check_2fg_scroll functionality available outside of touchpad.c ,
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>
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>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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>
Most trackpoint users want to be able to scroll using the trackpoint with
the middle button pressed, add support for 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>
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>
We previously called this function only before device removal, so failing to
update the button state didn't matter. To make this function generic for the
device suspend/resume, we need to keep track of the button/key count properly.
If we have a key down multiple times on suspend though, log a bug.
The dispatch should release the keys before we even get here (functionality
added in a subsequent patch).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A device may disappear and a new device may re-appear with the same device
node while the original device is suspended. Prevent a device resume to open
the wrong device.
In a path context, a changing syspath is the only indicator we get of the
device changing.
In a udev context, if the device was removed and libinput_dispatch() was
called, we can short-cut the syspath comparison by setting it to NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The evdev fallback dispatch supports enabling and disabling devices. That's
fairly easy to support since we don't (yet) have extra event generation within
the fallback backend. Thus, we can simply close the fd and re-open it again
later.
Touchpads are currently excluded here, they generate extra events on tapping,
scrolling, and software buttons and need a more complex implementation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
