1. 28 Apr, 2017 1 commit
  2. 26 Apr, 2017 1 commit
  3. 21 Apr, 2017 1 commit
  4. 30 Jan, 2017 2 commits
    • Peter Hutterer's avatar
      evdev: improve type-safety on dispatch switches · 60de087e
      Peter Hutterer authored
      Set the dispatch type on creation, then check that whenever we try to get the
      dispatch struct. This avoids a potential mismatch between the backends.
      Plus, use of container_of means we're not dependent on the exact layout
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      touchpad: use pressure values for touch is-down decision · 568d527c
      Peter Hutterer authored
      Don't rely on BTN_TOUCH for "finger down", the value for that is hardcoded in
      the kernel and not always suitable. Some devices need a different value to
      avoid reacting to accidental touches or hovering fingers.
      Implement a basic Schmitt trigger, same as we have in the synaptics driver. We
      also take the default values from there but these will likely see some
      A special case is when we have more fingers down than slots. Since we can't
      detect the pressure on fake fingers (we only get a bit for 'is down') we
      assume that *all* fingers are down with sufficient pressure. It's too much of
      a niche case to have this work any other way.
      This patch drops the handling of ABS_DISTANCE because it's simply not needed
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  5. 26 Jan, 2017 2 commits
  6. 23 Jan, 2017 1 commit
  7. 14 Dec, 2016 1 commit
  8. 29 Nov, 2016 1 commit
  9. 12 Sep, 2016 1 commit
  10. 07 Sep, 2016 1 commit
    • Peter Hutterer's avatar
      tablet: add touch arbitration · b519ea4a
      Peter Hutterer authored
      So far we've relied on the wacom kernel module to do touch arbitration for us
      but that won't be the case in upcoming kernels. Implement touch arbitration in
      userspace by pairing the two devices and suspending the touch device whenever
      a tool comes into proximity.
      In the future more sophisticated arbitration can be done (e.g. only touches
      which are close to the pen) but let's burn that bridge when we have to cross
      Note that touch arbitration is "device suspend light", i.e. we leave the
      device enabled and the fd is active. Tablet interactions are comparatively
      short-lived, so closing the fd and asking logind for a new one every time the
      pen changes proximity is suboptimal. Instead, we just keep a boolean around
      and discard all events while it is set.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
  11. 14 Aug, 2016 1 commit
  12. 04 Aug, 2016 1 commit
  13. 20 Jul, 2016 2 commits
  14. 03 Jul, 2016 1 commit
  15. 19 Jun, 2016 1 commit
  16. 09 Jun, 2016 1 commit
  17. 01 Jun, 2016 1 commit
  18. 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>
  19. 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>
  20. 30 Mar, 2016 1 commit
  21. 11 Mar, 2016 1 commit
  22. 18 Feb, 2016 1 commit
  23. 04 Feb, 2016 1 commit
  24. 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>
  25. 24 Jan, 2016 1 commit
  26. 20 Jan, 2016 3 commits
  27. 18 Jan, 2016 1 commit
  28. 13 Jan, 2016 1 commit
  29. 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>
  30. 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>
  31. 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>
  32. 28 Jul, 2015 1 commit
  33. 23 Jul, 2015 3 commits