Now that we've separate handling of the EDGE_NEW vs EDGE states in
tp_edge_scroll_post_events() we can drop the threshold variable, in EDGE_NEW
we always want to check against DEFAULT_SCROLL_THRESHOLD and in the EDGE
state we only want to make sure that the delta != 0.0 which is already
checked later on in tp_edge_scroll_post_events().
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 previous setting of 10 wasn't 10 mm, it was used against the deltas
normalized to a 1000DPI mouse, i.e. closer to 4mm. It was also also per-event,
so a slow movement or a high-frequency touchpad can struggle to meet the
threshold.
Change the trigger to be ~5 mm from the initial touch down, accumulated until
we either meet the threshold or the timeout expires. The first scroll event
includes the delta since the touch down rather than the most recent delta.
This removes the delay otherwise seen in scrolling and makes the scroll motion
match the finger motion. This accumulated delta only applies when exceeding
the motion threshold, when the timeout triggers the switch to scrolling the
first delta posted is the current delta.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Previous code used a device coordinate threshold of 300 which won't work on
Elantech touchpads (1280 vs the ~4000 that synaptics has).
Convert to normalized DPI and reduce the threshold to 3mm.
https://bugs.freedesktop.org/show_bug.cgi?id=89206
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ideally we want to specify various thresholds in mm, but not all touchpads
set the hardware resolutions. Rather than conditions to check for resolutions
everywhere, use a macro to give us a normalized value that we use for motion
as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
On a semi-mt device lifting slot 0 before slot 1 makes slots 1 become slot 0
(with the matching coordinate jump), potentially triggering the tap movement
threshold.
On one test we can just swap the release order, the other test we need to
disable (the _inverted version of this test tests the other order anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And merge all current API versions into the same block. This isn't technically
necessary since removing libinput_has_button from the code will remove it from
the exported list. That trips up test/symbols-leak-test though.
Since we break the API and bump the soname in this release anyway, move
to a single block so the initial stable API is all nicely grouped together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fake proximity events are context dependent and libinput doesn't have access
to the context. For example, fake proximity on the Wacom mouse is only required
in relative mode - but whether to use relative or absolute events is decided
in the caller.
Document what the recommended approach is since it's a bit quirky and leave it
at that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This affects the touch device on graphics tablets.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Clickpads have BTN_LEFT but no BTN_RIGHT, non-clickpads must have both.
Tablet touch devices don't have any buttons, so skip the warning for those.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Works as a touchpad but has no buttons.
Minor change to one of the touchpad tests: because the touch area is so big
the slow-scrolling trigger needs to be adjusted.
And because the device is an external device, the "disable on external mouse"
test needs to be adjusted.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These tests make sure we don't get tapping events in certain situations
(finger movement, timeouts, ...). Tapping must be enabled for that to be a
valid test.
The tests can't work on semi-mt devices because we can't end slots
independently. Disable the tests there.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If we send BTN_LEFT or similar, we need the LITEST_BUTTON capability on the
device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Split out into a btntool test and a true three-finger test. For consistency,
check the number of slots on all those tests rather than having
litest-device-specific exclusions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No effect, all devices currently have tapping disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The event sequences we use for plam detection trigger tap events if enabled by
default. Always disable tapping, a set of tests for tapping in the palm
exclusion zones. Arguably, tapping in the zones should be handled in a
separate set of tests though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a tool is in proximity when we init, send a proximity event immediately.
This is only partially reliable due to the current kernel behavior:
* if the tool comes into proximity when there is no evdev client, the device
won't send any events and must be lifted out-of-proximity first. Patch is in
the works, see https://patchwork.kernel.org/patch/5924611/
* before 3.19, if the tool was in proximity (with an evdev client attached),
but goes out of proximity and back in with no client connected, we get an
immediate proximity out event from the kernel once we connect to the device
and no further events after that.
See kernel commit b905811a49bcd6e6726ce5bbb591f57aaddfd3be
Otherwise, things work as expected. The above should be fixed in the kernel
anyway.
Note that this changes the order of events during a udev seat init, before we
had all DEVICE_ADDED events in a row, now the proximity event may be
interspersed.
Reported-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The devices were never added to the libinput context we were checking, and the
while loop would quietly ignore not getting any events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Equivalent to the pointer axis function - it gets the mouse wheel clicks from
the tablet mouse.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Providing a relative axis in the axis_get_value() is inconsistent with the
other axes, this will be fixed in a follow-up commit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Split out the actual axis printing into a helper function and call that from
the main tablet proximity/axis print functions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
The little wheel isn't a full wheel, it has a ~90 degree rotation angle with a
range of 1024 values. To avoid confusion with "wheel" elsewhere in the API
name it slider.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Needs to be calculated from the x/y tilt values, the mouse has a fixed offset
of 175 degrees counterclockwise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
libwacom can tell us how many buttons we have per stylus, so we map those into
BTN_STYLUS and BTN_STYLUS2.
BTN_TOUCH is set on all styli.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Expand the mask to fit KEY_CNT buttons, the mouse has LMR buttons and a few
more, trying to squash the range is more error-prone than having the full key
range instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
This gets more complicated for axes that aren't a 1:1 relationship with event
codes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
ABS_THROTTLE:
Tablets still advertise this axis but the mouse itself isn't available
anymore. The Pad sends the second wheel as ABS_THROTTLE but that's a
task for the buttonset interface. Explanation of what the throttle
did on page
http://101.wacom.com/productsupport/manual/Intuos2UsersManual.pdf
ABS_RX/ABS_RY:
These only happen on the Intuos3 device and only on the Pad device
(kernel >= 3.17)
ABS_RZ:
The 4D mouse for the Intuos2, obsolete.
No functional changes, this is to clarify why we're only handling a subset of
codes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
A tablet hotplug event is rare and not a time-critical event, so we load the
database on tablet init and throw it away again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
