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>
Before this commit the tap code deals with enabled being set to false,
by waiting for tap.state to become IDLE, and then ignoring any events from
that point on.
This causes a problem when enabled gets set to true again while fingers are
down, because when in IDLE no release events are expected, so once a release
event for one of the fingers is send, log_bug_libinput gets called.
This commit fixes this by making enabled use the same mechanism for enabled
state transitions as the tap suspend / resume code.
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 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>
While e.g. disabling the touchpad while the trackpoint is used, we want to
stop sending tap (or scroll or motion) events. We cannot use tp_clear_state at
this time as that will also release any touchpad buttons pressed, breaking
dragging with the trackpoint using the touchpad or clickpad buttons.
Calling tp_release_all_taps() and then ensuring that we do not call
tp_tap_handle_state as long as the trackpoint is in use, is enough to disable
taps when the trackpoint is in use.
However when the trackpoint stops being used, we cannot simply start calling
tp_tap_handle_state() again, we first need to sync the tap.state to the current
reality, specifically if fingers are down it must be TAP_STATE_DEAD, so that
their releases do not trigger the log_bug_libinput on a release in
tp_tap_idle_handle_event.
Directly messing with tap.state from outside evdev-mt-touchpad-tap.c is not
good, so add tp_tap_suspend and tp_tap_resume functions 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>
Before this commit tp_release_all_taps would call tp_tap_handle_timeout, which
is a nop when in state DRAGGING. tp_clear_state then releases all touches and
calls touchpad_handle_state which moves the state to DRAGGING_WAIT, and the
button 1 release will only be done after the tap-timeout, rather then directly
as it should on tp_clear_state.
This commit fixes this by instead of calling tp_tap_handle_timeout, directly
releasing pressed buttons and switching to state DEAD or IDLE depending on
fingers_down.
Besides fixing this issue, this rewrite also makes it possible to use
tp_release_all_taps outside of tp_clear_state, which will be used to add
tap suspend / resume functionality in a follow up commit.
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: 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 features like e.g. disable-touchpad-while-typing, it is necessary for one
device to be able to listen into another device's events.
It is tempting to use the existing device_added / device_removed mechanism
to give e.g. the keyboard a link to the touchpad, and make the keyboard code
disable / re-enable the touchpad but this is wrong. This needs to be a setting
of the touchpad, and the policy for things like which events to count as
activity, and what sort of timeout to use to consider the device idle, belongs
in the touchpad code not in the keyboard code.
Add an event listeners mechanism so that the touchpad can listen for (e.g.)
keyboard events, and respond to these 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>
This is a preparation patch for adding internal event listeners, so that the
callbacks for these can get the full 64 bit timestamps.
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 libinput evdev code uses 64 bit timestamps internally, to avoid having to
deal with timestamp wraps. The internal foo_notify_bar functions time argument
however is only 32 bits, bump this to 64 bits to avoid truncating the timestamps
when calling these functions.
This is a preparation patch for adding internal event listeners, so that the
callbacks for these can get the full 64 bit timestamps.
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>
Assume "normal" mice are 400DPI, and that all calculations should be
normalized to this before being fed into the filter.
There isn't yet a way to configure a device's DPI.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Converting to integer before the sqrt calculation can cause loss of
motion at low speed.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Log a message when the kernel event queue overflows and events are dropped.
After 10 messages logging stops to avoid flooding the logs if the condition
is persistent.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
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>
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>
