Middle button interaction is most commonly to paste and it is a single-event
interaction (button press). We provided middle button in software button mode
by emulating it with a two-finger press with L+R down at the same time. This
is also what many touchpads are spectacularly bad at, it is very common to
detect the physical button down event before the second finger registers,
resulting in left or right clicks where a middle button should be triggered.
Unless the fingers are resting on the touchpad for at least one scanout, the
success rate for middle button emulation is only at 70% or so.
This patch adds a 25%-width middle button area between the left and the right
software button, everything else stays the same. To avoid immediate breakage,
the middle button emulation remains but may be removed in the future.
The doc is updated to only refer to the middle button area now.
https://bugs.freedesktop.org/show_bug.cgi?id=94755
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
It's reasonable to expect a thumb (or the other hand's index finger) to click
a button while a finger is down for movement. It's less reasonable to expect
this when two fingers are interacting with the touchpad, or when two fingers
click the touchpad (even on a large touchpad that's an awkward position).
Simplify the clickfinger detection mechanism - if we have three touches down,
it's always a three-finger click. Two fingers may be a right click or a index
+ thumb click.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We're again hitting the fork ulimits again (see also 9c2afae14) causing test
case failures in the valgrind run of the touchpad test.
Split out the touchpad button tests so we don't require special ulimits on
test boxes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
