1. 21 Mar, 2019 1 commit
  2. 18 Mar, 2019 1 commit
    • Paolo Giangrandi's avatar
      touchpad: multitap state transitions use the same timing used for taps · a88d73ce
      Paolo Giangrandi authored
      Multitap sequences (more than 2 taps) had a 180ms timer set only on press,
      not on release.
      New taps within those 180ms could either trigger multitap+drag or another
      multitap (for N+1 taps), resetting the timer on press once again.
      If no new tap appears within those 180ms, the sequence was considered
      This behavior differed from regular taps: for the very first tap of a
      sequence the timer was set both on touch and on release.
      The multitap timing caused misdetection of triple-tap-and-drag sequences as
      the timer was hit frequently. Some of those were correctly detected, others
      as tripletap only.
      Changing the timer to be set on press **and** release gives us a more lenient
      timeout. 180ms for tap-and-drag and 180ms for the next tap down after
      release. This was also the behavior for the xorg synaptics driver.
      Note that quadruple-tap-and-drag didn't suffer from this because the timeout
      resulted in double-tap + double-tap-and-drag. Which has the same
      user-visible effect.
  3. 17 Mar, 2019 1 commit
  4. 15 Mar, 2019 2 commits
  5. 14 Mar, 2019 11 commits
  6. 12 Mar, 2019 5 commits
  7. 06 Mar, 2019 1 commit
  8. 04 Mar, 2019 5 commits
  9. 19 Feb, 2019 1 commit
    • Henré Botha's avatar
      Reduce button scroll timeout to 38ms · 5dae7aac
      Henré Botha authored
      When using button scrolling, a hardcoded delay of 200 milliseconds between
      button down and scroll events being emitted makes fast scrolling gestures feel
      clunky and sometimes fail entirely. This feature comes from
      xf86-input-mouse, was copied into xf86-input-evdev and reimplemented in
      This was, as far as can be determined, to allow right clicks without
      triggering scrolling. libinput now also has distance triggers (2bbf4a01)
      and sends button events if no movement has happened for long clicks,
      regardless of the delay.
      The 200ms delay is thus not really necessary anymore, let's drop it to 38ms
      which is just above the 3-event threshold for 8/10/12ms intervals which is
      most devices.
      Fixes #237
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  10. 18 Feb, 2019 1 commit
  11. 14 Feb, 2019 9 commits
  12. 13 Feb, 2019 2 commits