1. 01 Sep, 2017 3 commits
  2. 28 Aug, 2017 1 commit
  3. 27 Aug, 2017 2 commits
  4. 23 Aug, 2017 2 commits
  5. 21 Aug, 2017 1 commit
  6. 20 Aug, 2017 1 commit
  7. 17 Aug, 2017 2 commits
  8. 16 Aug, 2017 1 commit
  9. 14 Aug, 2017 1 commit
  10. 04 Aug, 2017 1 commit
  11. 01 Aug, 2017 3 commits
    • Hans de Goede's avatar
      touchpad: Enable timestamp smoothing support for bluetooth touchpads · c4857f01
      Hans de Goede authored
      Bluetooth wreaks havoc with the timestamp of the input events coming
      from the touchpad, enable timestamp smoothing support to counter this.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      c4857f01
    • Hans de Goede's avatar
      filter: Add timestamp smoothing support · 6f39a9e1
      Hans de Goede authored
      Some devices, specifically some bluetooth touchpads generate quite
      unreliable timestamps for their events. The problem seems to be that
      (some of) these touchpads sample at aprox 90 Hz, but the bluetooth stack
      only communicates about every 30 ms (*) and then sends mutiple HID input
      reports in one batch.
      
      This results in 2-4 packets / SYNs every 30 ms. With timestamps really
      close together. The finger coordinate deltas in these packets change by
      aprox. the same amount between each packet when moving a finger at
      constant speed. But the time deltas are e.g. 28 ms, 1 ms, 1 ms resulting
      in calculate_tracker_velocity returning vastly different speeds for the
      1st and 2nd packet, which in turn results in very "jerky" mouse pointer
      movement.
      
      *) Maybe it is waiting for a transmit time slot or some such.
      
      This commit adds support for a real simple timestamp smoothing algorithm,
      intended *only* for use with touchpads. Since touchpads will send a
      contineous stream of events at their sample rate when a finger is down,
      this filter simply assumes that any events which are under
      event_delta_smooth_threshold us apart are part of a smooth continuous
      stream of events with each event being event_delta_smooth_value us apart.
      
      Theoritically a very still finger may send the exact same coordinates
      and pressure twice, but even if this happens that is not a problem because
      a still finger generates coordinates changes below the hyst treshold so
      we ignore it anyways.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      6f39a9e1
    • Peter Hutterer's avatar
      gestures: don't try to pinch for nfingers > slots · 6d435cda
      Peter Hutterer authored
      We don't know the position of the third finger on 2-slot touchpads, differing
      between swipe and pinch is reliable. Simply disable 3-finger pinch and always
      use swipe; 3fg pinch is uncommon anyway and it's better to have one of the
      gestures working reliably than both unreliably.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      6d435cda
  12. 27 Jul, 2017 1 commit
  13. 25 Jul, 2017 3 commits
    • Peter Hutterer's avatar
      pointer: add button debouncing · 55d1bb12
      Peter Hutterer authored
      Some devices have worn-out switches or just cheap switches that trigger
      multiple button events for each press. These can be identified by unfeasably
      short time deltas between the release and the next press event. In the
      recordings I've seen so far, that timeout is 8ms.
      
      We have a two-stage behavior: by default, we do not delay any events but we
      monitor timestamps. The first time a bouncing button is detected we switch to
      debounce mode. From then on, release events are delayed slightly to check for
      subsequent button events. If one occurs, the releas and press are filtered. If
      none occurs, the release event is passed to the caller.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=100057Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      55d1bb12
    • Peter Hutterer's avatar
      timer: always restart the timer loop when we called one of them · 6d0edf9d
      Peter Hutterer authored
      If a timer_func causes the removal or addition of a different timer, our tmp
      pointer from the list_for_each_safe may not be valid anymore.
      
      This was triggered by having the debounce code trigger a middle button state
      change, which caused that timer to be cancelled.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      6d0edf9d
    • Peter Hutterer's avatar
      timer: if a timer is inactive, do not call the timer func · 696fdff2
      Peter Hutterer authored
      Race conditions may happen where code that cancels a timer is called just
      as that timer triggers. If we cancel a timer, we assume that we've put the
      code into a state where the timer firing will trigger a bug.
      
      This could be observed with the middle button code if the release event was
      held back just long enough. The button release code cancelled the timer, set
      the state back to idle and then complained when the timeout handling sent a
      'timeout' event while being in idle.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      696fdff2
  14. 24 Jul, 2017 1 commit
  15. 20 Jul, 2017 5 commits
  16. 19 Jul, 2017 1 commit
  17. 14 Jul, 2017 1 commit
  18. 12 Jul, 2017 6 commits
  19. 11 Jul, 2017 4 commits