Skip to content

GitLab

L
libinput
Switch branch/tag
  1. 14 Aug, 2016 1 commit
  3. 04 Aug, 2016 1 commit
  5. 20 Jul, 2016 2 commits
  7. 03 Jul, 2016 1 commit
  9. 19 Jun, 2016 1 commit
  11. 09 Jun, 2016 1 commit
  13. 01 Jun, 2016 1 commit
  15. 05 Apr, 2016 1 commit
    • Peter Hutterer's avatar
      touchpad: add a middle button software area · 886b5a2c
      Peter Hutterer authored 
      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=94755Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      886b5a2c
  17. 04 Apr, 2016 1 commit
    • Peter Hutterer's avatar
      touchpad: reset the motion history on significant negative pressure changes · ef48c07a
      Peter Hutterer authored 
      Resetting the motion history has the side-effect of swallowing movements, we
don't calculate deltas until we have 4 motion events. During a finger release,
we're likely to get a large pressure change between two events, resetting the
motion history prevents the cursor from jumping on release.

The value of 7 found by trial-and-error, tested on the T440 and T450 hardware.
The absolute value is highly variable but recordings show that the pressure
changes only by 1 or 2 units during normal interaction. Higher pressure
changes are during finger position changes but since those should not cause a
jump anyway, we tend to win there too.

Currently only enabled for negative pressure changes, let's see how we go with
that. This is enabled for all touchpads now, but the value may need
device-specific thresholds in the future.

https://bugs.freedesktop.org/show_bug.cgi?id=94379Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      ef48c07a
  19. 30 Mar, 2016 1 commit
  21. 11 Mar, 2016 1 commit
  23. 18 Feb, 2016 1 commit
  25. 04 Feb, 2016 1 commit
  27. 27 Jan, 2016 1 commit
    • Peter Hutterer's avatar
      touchpad: add a config option to disable tap-and-drag · cba2278c
      Peter Hutterer authored 
      There are a number of use-cases where tapping may be desirable, but
tap-and-drag is not, e.g. where tapping is used to select multiple items in a
list. Having tap-and-drag on hinders this, and the nature of the interaction
means it cannot be detected based on timeouts, movement thresholds, etc.

Provide an option instead to turn tap-an-drag off. Tap-and-drag remains
enabled by default (though tapping is disabled by default).

For the touchpad tap state diagram, the new option disables the transition
from state TOUCH to state TAPPED and releases the button immediately instead.
This means that multitap-and-drag is disabled too since we now just loop
around in the single-tap state for multitap.

It also makes tapping more responsive - we don't have to wait for the timeout
before we know whether it's a tap event. The first touch time is noted, we now
send the button press with the time of the first touch and the release with
the time of the release. This ensures a realistic time diff between the two
events.

https://bugs.freedesktop.org/show_bug.cgi?id=93502Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.netto>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      cba2278c
  29. 24 Jan, 2016 1 commit
  31. 20 Jan, 2016 3 commits
  33. 18 Jan, 2016 1 commit
  35. 13 Jan, 2016 1 commit
  37. 06 Sep, 2015 1 commit
    • Peter Hutterer's avatar
      touchpad: don't tap for 2fg down, followed by a single finger up · 79570fd4
      Peter Hutterer authored 
      The following sequence currently generates a right-button event:
	finger 1 down
	finger 2 down
	finger 1 up
	finger 2 held down

This is easily triggered with short scroll events. There are two issues here:
first is that the tapping code elsewhere treats any tap with a second finger
down as a left-button tap, not a right button one. So if anything, we should
generate a left button click here, not a right button click.

Arguably, generating a button click here is wrong though, it's not a very well
defined sequence and relatively difficult to trigger intentionally. So the
best solution here is to simply ignore the release event and move straight
back to state HOLD - unless the second finger is released within the timeout.
If the finger is set down again during the timeout, we move straight to
TOUCH_2_HOLD - this could eventually be interpreted as a tap, but not for now.
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      79570fd4
  39. 19 Aug, 2015 1 commit
    • Peter Hutterer's avatar
      touchpad: use unaccelerated motion data for scrolling · c8da19b5
      Peter Hutterer authored 
      For short and quick scroll gestures, those that should only trigger a few
lines of scroll the pointer acceleration is wildly unpredictable. Since we
average the motion of both fingers it's hard enough to intuitively predict
what the motion will be like. On top of that is the small threshold before we
start scrolling, so some of the initial motion gets swallowed before we
accelerate, making the next motion even more unpredictable.

The end result is that multiple seemingly identical finger motions cause
wildly different scroll motion.

Drop pointer acceleration for two-finger and edge scrolling. This makes short
scroll motions much more predictable and doesn't seem to have much effect on
long scroll motions. Plus, in natural scroll mode it really feels like the
content is stuck to your fingers now. Go wash your hands.

https://bugzilla.redhat.com/show_bug.cgi?id=1249365Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      c8da19b5
  41. 03 Aug, 2015 1 commit
    • Peter Hutterer's avatar
      touchpad: make gestures optional · 6295118c
      Peter Hutterer authored 
      Not all multi-finger touchpads are able to reliably produce gestures, so make
it optional. This patch just adds a boolean (currently always true) that gets
set on touchpad init time, i.e. it is not run-time configurable.

Three and four-finger gestures are filtered out in gesture_notify(), if the
cap isn't set the event is discarded.

For two-finger gestures we prevent a transition to PINCH, so we don't
inadvertently detect a pinch gesture and then not send events. This way, a 2fg
gesture is always scroll.
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      6295118c
  43. 28 Jul, 2015 1 commit
  45. 23 Jul, 2015 3 commits
  47. 22 Jul, 2015 1 commit
    • Peter Hutterer's avatar
      touchpad: reset the motion history during/after a slots->nfake crossover · a87d51f9
      Peter Hutterer authored 
      Whenever we cross from N slots to at least one fake finger, reset the motion
history and skip the next event too. Especially on serial Synaptics touchpads,
the first touch update after a two-slot → TRIPLETAP is garbage, as is the one
from TRIPLETAP → two slots.

Example sequence reproduce on a T440s:

E: 4.488757 0003 003a 0084      # EV_ABS / ABS_MT_PRESSURE      84
E: 4.488757 0003 002f 0001      # EV_ABS / ABS_MT_SLOT          1
E: 4.488757 0003 0039 0433      # EV_ABS / ABS_MT_TRACKING_ID   433
E: 4.488757 0003 0035 2500      # EV_ABS / ABS_MT_POSITION_X    2500
E: 4.488757 0003 0036 3064      # EV_ABS / ABS_MT_POSITION_Y    3064
E: 4.488757 0003 003a 0060      # EV_ABS / ABS_MT_PRESSURE      60
E: 4.488757 0003 0018 0084      # EV_ABS / ABS_PRESSURE         84
E: 4.488757 0001 0145 0000      # EV_KEY / BTN_TOOL_FINGER      0
E: 4.488757 0001 014e 0001      # EV_KEY / BTN_TOOL_TRIPLETAP   1
E: 4.488757 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 4.508506 0003 002f 0000      # EV_ABS / ABS_MT_SLOT          0
E: 4.508506 0003 0036 2982      # EV_ABS / ABS_MT_POSITION_Y    2982
E: 4.508506 0003 003a 0086      # EV_ABS / ABS_MT_PRESSURE      86
E: 4.508506 0003 002f 0001      # EV_ABS / ABS_MT_SLOT          1
E: 4.508506 0003 0035 3464      # EV_ABS / ABS_MT_POSITION_X    3464
E: 4.508506 0003 0036 2716      # EV_ABS / ABS_MT_POSITION_Y    2716
E: 4.508506 0003 0001 2982      # EV_ABS / ABS_Y                2982
E: 4.508506 0003 0018 0086      # EV_ABS / ABS_PRESSURE         86
E: 4.508506 0000 0000 0000      # ------------ SYN_REPORT (0) ----------

subsequent events then hover around the 3464 mark, but that initial jump is
enough to cause a massive cursor jump.

https://bugs.freedesktop.org/show_bug.cgi?id=91352Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
Hallelujah-expressed-by: Benjamin Tissoires's avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      a87d51f9
  49. 15 Jul, 2015 1 commit
  51. 09 Jul, 2015 1 commit
    • Peter Hutterer's avatar
      touchpad: add pressure-based thumb-detection · 3dcf28b9
      Peter Hutterer authored 
      All touchpad recordings seen so far show that a value above 100 is definitely
a thumb or a palm. Values below are harder to discern, and the same isn't true
for touchpads supporting ABS_PRESSURE instead of ABS_MT_PRESSURE.

The handling of a touch is as outlined in tp_thumb_detect:
* thumbs are ignored for pointer motion
* thumbs cancel gestures
* thumbs are ignored for clickfinger count
* edge scrolling doesn't care either way
* software buttons don't care either way
* tap: only if thumb on begin

The handling of thumbs while tapping is the simplest approach only, more to
come in follow-up patches.

Note that "thumb" is the synonym for "this touch is too big to be a
fingertip". Which means that a light thumb touch will still be counted as a
finger. The side-effect here is that thumbs resting a the bottom edge of the
touchpad will almost certainly not trigger the pressure threshold because
most of the thumb is off the touchpad.
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      3dcf28b9
  53. 06 Jul, 2015 3 commits
  55. 02 Jul, 2015 1 commit
    • Peter Hutterer's avatar
      Drop motion normalization of unaccelerated deltas · c06d825c
      Peter Hutterer authored 
      This simply doesn't work for low-dpi mice. Normalizing a 400dpi mouse to a
1000dpi mouse forces a minimum movement of 2.5 units and the resulting pixel
jumps. It is impossible for the caller to detect whether the jump was caused
by a single motion or multiple motion events.

This is technically an API break, but not really.

The accelerated data was already relatively meaningless, even if normalized as
the data did not correspond predictably to any input motion (unless you know
the implementation acceleration function in the caller). So we can drop the
mention from there without expecting any ill effects in the caller.

The unaccelerated data was useless for low-dpi mice and could only be used to
measure the physical distance of the mouse movement - something not used in
any caller we're aware of (if needed, we can add that functionality as a
separate call). Dropping motion normalization for unaccelerated deltas also
restores true dpi capabilities to users of that API, mostly games that want to
make use of high-dpi mice.

This is a simplified patch, the normalization is still in place for most of
libinput, it merely carries the original coordinates in the event itself.

In the case of touchpads, the coordinates are unnormalized into the x-axis
coordinate space as per the documentation.
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      c06d825c
  57. 30 Jun, 2015 3 commits
  59. 23 Jun, 2015 1 commit
  61. 21 Jun, 2015 1 commit