1. 14 Aug, 2016 1 commit
  2. 04 Aug, 2016 1 commit
  3. 20 Jul, 2016 2 commits
  4. 03 Jul, 2016 1 commit
  5. 19 Jun, 2016 1 commit
  6. 09 Jun, 2016 1 commit
  7. 01 Jun, 2016 1 commit
  8. 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>
  9. 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>
  10. 30 Mar, 2016 1 commit
  11. 11 Mar, 2016 1 commit
  12. 18 Feb, 2016 1 commit
  13. 04 Feb, 2016 1 commit
  14. 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
      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>
  15. 24 Jan, 2016 1 commit
  16. 20 Jan, 2016 3 commits
  17. 18 Jan, 2016 1 commit
  18. 13 Jan, 2016 1 commit
  19. 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>
  20. 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>
  21. 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>
  22. 28 Jul, 2015 1 commit
  23. 23 Jul, 2015 3 commits
  24. 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>
  25. 15 Jul, 2015 1 commit
  26. 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>
  27. 06 Jul, 2015 3 commits
  28. 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>
  29. 30 Jun, 2015 3 commits
  30. 23 Jun, 2015 1 commit
  31. 21 Jun, 2015 1 commit