Just setting one of them on a device doesn't guarantee that libinput takes
that as device type.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The goal of this test is to make sure that the deltas are less than 5, which
is the scroll trigger for movement-based edge scrolling. The litest suite
takes percentages of the device, so use a scale factor to change how far we
move on the tablet. The wacom tablet is 141mm, the movement must be smaller to
provide small-enough deltas.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The single finger requirement dates back to when we couldn't configure the
scroll method. Now we can, so let's run the tests on as many suitable devices
as possible.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Just to make sure it is enabled (it should be anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is sort-of legitimate, so simply disable the axes and continue.
Any real axis we require to have a real range.
https://bugs.freedesktop.org/show_bug.cgi?id=90090
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Once we have a doubletap, enter a loop in the state machine where we can tap
multiple times and either get a multi-click or a multi-click drag-and-drop.
The sequence down/up down/up down/up produces a triple-click. The sequence
down/up down/up down/up down produces a triple-click with a button down for
dragging. Yes, that glorious octuple-tap-and-drag, it is now possible. World
domination has been achieved, thank you for playing.
We don't know when we finish tapping now, so add a timeout to send the last
click event once the finger has been released for the last time. This
guarantees that the timestamp of the last button down is later than the
last release. This avoids the bug fixed in synaptics commit
xf86-input-synaptics-1.8.0-21-g37d34f0 (some application don't handle
doubletap correctly without the timestamps).
This works for double-tap immediately, for multi-tap we need to remember the
timestamp of the first press event and use it for the release event so that
there's a forced gap between the release and the second press.
https://bugs.freedesktop.org/show_bug.cgi?id=89511
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Makes it easier from a caller to check for common things without all the other
boilerplate code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If the touchpad has left/right physical buttons but no middle button, force
middle button emulation - without a config option, it's always on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Devices that have left and right buttons but no middle button get middle
button emulation (without config). Devices that have a middle button too get
a config option but default to off. Most mice have LMR set as buttons,
regardless whether they have a middle button.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is just the required framework, it's not hooked up to anything just yet.
Hooking it up comes as separate commit to better detail why/when a device
supports emulation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Adds the following quartett of functions to enable/disable middle mouse button
emulation on a device:
libinput_device_config_middle_emulation_is_available()
libinput_device_config_middle_emulation_set_enabled()
libinput_device_config_middle_emulation_get_enabled()
libinput_device_config_middle_emulation_get_default_enabled()
This patch only adds the config framework, it is not hooked up to anything
yet.
Note: like other features this is merely the config option, some devices will
provide middle button emulation without exposing it as configuration. i.e. the
return value of libinput_device_config_middle_emulation_is_available() only
tells you whether you can _configure_ middle button emulation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes at this point, this merely splits up any physical
buttons (i.e. that represent buttons that exist on that device) vs. other
buttons that are emulated in some way or another.
This is in preparation for the addition of middle button emulation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1209753 lists a touchpad 76mm wide
that suffers from palm touches
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Touches in the exclusion zone are ignored for palm detection and don't move
the cursor. Tapping however triggers before we know whether something is a
palm or not, so we get erroneous button clickst.
If a tap happens in the top half of the touchpad, within the palm exclusion
zones, ignore it for tap purposes. To avoid further complicating the state
machine simply pretend there was a movement > threshold on that finger. This
advances the tap state machine properly that no button events are sent for
this finger.
https://bugs.freedesktop.org/show_bug.cgi?id=89625
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Internal touchpads with trackpoints are either BUS_I8042 or BUS_I2C, but not
BUS_USB. Lenovo sells external keyboards with a trackpoint built-in, make sure
we don't pair that trackpoint with the internal touchpad.
And likewise, the internal trackpoint should not be paired with e.g. a wacom
touch device.
Lenovo had one external device that has a trackpoint and a touchpad on an
external keyboard. That device won't be covered with this patch, if we have a
user we can re-consider.
https://bugs.freedesktop.org/show_bug.cgi?id=89935
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
xinput or an equivalent isn't available under wayland, but the majority of
use-cases of "why doesn't my device work" or "why does feature X not work"
should be covered by simply listing the local devices and their config
options.
Example output:
Device: SynPS/2 Synaptics TouchPad
Kernel: /dev/input/event4
Group: 9
Seat: seat0, default
Size: 97.33x62.40mm
Capabilities: pointer
Tap-to-click: disabled
Left-handed: disabled
Nat.scrolling: disabled
Calibration: n/a
Scroll methods: *two-finger
Click methods: *button-areas clickfinger
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This currently requires a specific udev rule to tag the device, once the
matching bits are upstream we can drop this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Follow-up to e2f61b8fb7.
Scroll events are sent through the pointer interface, so we must set the
capability. Otherwise a caller may not have the required bits set up and is a
bit surprised by events coming out of an interface the device doesn't actually
have (xf86-input-libinput crashes when this happens).
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Prints the various pointer accel behaviors into a format understood by
gnuplot, which then provides prettiness.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The main purpose of this patch is to allow the user to actually slow
down pointer movement using libinput_device_config_accel_set_speed, this
is achieved by changing the max-accel setting from "2.0 - speed" to
"2.0 - speed * 1.5", resulting in a max-accel of 0.5 when the user configures
speed at -1.0, the other accel profile parameters are adjusted by the same
factor to keep the curve the same.
This means that the user can get the exact same behavior as before by
multiplying the old setting by 0.6667 (2/3), this also means that this
change not only allows the user to select a slower speed, but to keep
things balanced the same as before, also a higher speed.
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>
Less ambiguous since real_touches can be interpreted to "current number of
real touches as opposed to fake touches". Which it isn't, this variable holds
the number of slots.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Up to QUINTTAP, we count fake fingers through the BTN_TOOL_*TAP kernel defines.
Once we exceed QUINTTAP, the nfake_finger count returns to 0 and
tp_unhover_touches terminates all touch sequences. The most visible effect of
this was stopped in 591a41f but the problem remained.
Since we're not using 5 fingers for anything, use that to set the
overflow flag. The kernel gives us either a BTN_TOUCH 0 (all
released) or a lower BTN_TOOL_*TAP to unset the flag when we go below 5
fingers again.
And if we overflow, we can skip the unhovering of touch points since we a)
have a decent touchpad that gives us real touchpoints and b) hovering isn't
supported for 5 touches anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=89800
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is a kernel bug, reject such devices outright. This saves us from a bunch
of extra double checks to make sure that the resolutions are always set up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A switch from BTN_TOOL_FINGER to BTN_TOOL_DOUBLETAP sets the former to 0, then
the latter to 1, within the same frame. In the previous code we'd end the
first touchpoint, then start two new ones immediately after when the DOUBLETAP
comes in. This causes bug notices in the edge scrolling code and finger
miscounts in the tapping code (since neither processes the change, there is no
SYN_REPORT between the two).
Only update the state bits when we get the events, handle the fake touch
sequence start/end on SYN_REPORT instead.
https://bugs.freedesktop.org/show_bug.cgi?id=89949
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regression introduced in 9f8edc5fd8 where it
changed from delta / (dpi/default) to delta * dpi/default, causing the inverse
effect of what the dpi setting is supposed to achieve.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
tp->nfingers_down gives us the current state of the touchpad but in the case
of the tapping state we need the touchpoints separately. If all touchpoints
end in the same SYN_REPORT frame, tp->nfingers_down is 0 when we handle the
touch releases. This changes the tap state to IDLE on the first release and
then logs a bug when the remaining touches are released while the touchpad is
in IDLE.
Avoid this by counting the fingers separately for the tap state, this way we
can count up/down with the down/up events as we process them for the tapping
state machine.
This also adds tests for 4 and 5-finger tapping which is how the bug was
discovered in the first place.
https://bugs.freedesktop.org/show_bug.cgi?id=89800
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This device has a couple of axes (fake MT) and a wheel. The device itself
exports 4 nodes, this device is the second node, the most problematic one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
