Measuring the trackpoint range has not shown to be sufficient or precise
enough to be used as an ingredient for trackpoint acceleration. So let's just
switch back to a generic multiplier that we can apply to the input deltas do
undo any device-specific lack of scaling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This seems to give me roughly the same behaviour as macos does on the default
0 speed setting.
* Default speed is lower than before by around 30% [1]
* Acceleration kicks in much sooner (130mm/s vs 250mm/s before)
* Acceleration kicks in slower at lower speeds, so the change from 130mm/s to
150mm/s is less than that of 320mm/s to 350mm/s
* The effect of the speed setting is a wide-range constant (de|ac)celeration
[2], which means:
* The unaccelerated baseline up until the threshold now changes with the
speed setting
* The threshold is now the same for all speeds
* The range of the speed setting should now easily cover all desired device
speeds.
* Acceleration is steeper at higher speeds
* Deceleration was left as-is.
[1] This may or may not fix the jumping pointer issues caused by the previous
high defaults. When you have high default acceleration you move the finger
slower. This slow movement caused some touchpads (mostly seen on Lenovos) to
create pointer jumps. These weren't seen on synaptics previously because of a
combination of higher user finger speed (thus not triggering the bug) or just
not being as obvious (2px jump vs 10 px jump).
[2] The speed setting is actually a curve, the closer you get to 1.0 the more
difference you see between two different values. The curve's points are:
-1/0, 0/1, 1/5, so the resolution is closer for slow speeds. We still have
double resolution on the setting though so you'll find what you want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looked good on paper but clearly no-one (including myself) ever tested this
in a real-life situation or they would've noticed that the constant factor is
missing, causing a segfault on the first two-finger scroll event, touchpad
gesture or button scrolling.
Adding the constant factor makes the API much worse and the benefit is
unclear, so out of the window it goes. We can revisit this for libinput 1.12
but this isn't going to make the next release.
This reverts commit d8bd650540.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This adds a third profile to the available profiles to map device-specific
speed to an acceleration factor, fully defined by the caller.
There has been a consistent call for different acceleration profiles in
libinput, but very little specifics in what actually needs to be changed.
"faster horses" and whatnot (some notable exceptions in e.g. bug 101139).
Attempts to change the actual acceleration function will likely break things
for others.
This approach opens up the profile itself to a user-specific acceleration
curve. A caller can set an acceleration curve by defining a number of points
on that curve to map input speed to an output factor. That factor is applied
to the input delta.
libinput does relatively little besides mapping the deltas to the
device-specific speed, querying the curve for that speed and applying that
factor. The curve is device-specific, the input speed is in device units/ms.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current debouncing code monitors events and switches on when events are
too close together. From then on, any event can be delayed.
Vicente Bergas provided an algorithm that avoids most of these delays:
on a button state change we now forward the change without delay but start a
timer. If the button changes state during that timer, the changes are
ignored. On timer expiry, events are sent to match the hardware state
with the client's view of the device. This is only done if needed.
Thus, a press-release sequence of: PRP sends a single press event, a sequence of
PRPR sends press and then the release at the end of the timeout. The timeout
is short enough that the delay should not be noticeable.
This new mode is called the 'bounce' mode. The old mode is now referred to as
'spurious' mode and only covers the case of a button held down that loses
contact. It works as before, monitoring a button for these spurious contact
losses and switching on. When on, button release events are delayed as before.
The whole button debouncing moves to a state machine which makes debugging a
lot easier. See the accompanying SVG for the diagram.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This reduces unexpected cursor moves when placing the thumb near the border
of trackpoint buttons and upper edge of touchpad.
https://bugs.freedesktop.org/show_bug.cgi?id=101574
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Separate patch to avoid crowding out the actual content in the patch with the
documentation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
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>
The newer Cintiqs have a minimum value of 400/400 advertised by the kernel but
the actual sensor goes past the 0/0 origin. Test this, make sure that a value
outside the boundaries generates negative mm values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not much we can do about this until we get SMBus/RMI4 in the kernel or better
touchpads in general but this way we can at least point to some official
explanation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There were two files (doc/svg/{edge,twofinger}-scrolling.svg) that had both
arrow heads pointing to wrong direction. Those arrow heads used markers but
their ids were defined wrong and therefore they displayed weirdly. On Firefox
the arrow head that should have pointed to left pointed actually to right.
This commit fixes that problem by defining the marker ids correctly.
I tested on Firefox 40.0.3 that the arrow heads are now displayed correctly.
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Tested-by: Bryce Harrington <bryce@osg.samsung.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
That's the most likely area it will be resting in, if it's sitting anywhere
above that it's likely part of an interaction.
A thumb in the lowest 15mm needs to trigger the pressure threshold before it's
labelled a thumb. A thumb in the lowest 8mm is considered a thumb if it
remains there for 300ms. Regardless of the pressure, since we can't reliably
get pressure here. If a thumb moves out of the area, or starts outside of that
area it is never a thumb.
If edge scrolling is enabled, the 8mm threshold is ineffective since we'll
have normal interaction in that zone for horizontal scrolling.
The thumb tests now require all touchpads to be switched to clickfinger, if we
test for thumb detection on the bottom of the pad we won't get expected
motion events due to the software button area.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A common use-case for clickfinger is to use the index finger for moving the
pointer, then triggering the click with a thumb. If the index finger isn't
lifted before the click this counted as two-finger click.
To avoid this, check the distance between touches on the touchpad (on
touchpads reporting resolution values anyway). If the touches are too far
apart, don't count them together (or specifically only count those close
enough together as multi-finger).
The touch area is uneven, it's wider than high. Spreading fingers horizontally
is more common and this also makes it easier to rule out thumbs which tend to
be well below the fingers.
http://bugs.freedesktop.org/show_bug.cgi?id=90526
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>
