1. 28 Aug, 2018 1 commit
    • Peter Hutterer's avatar
      test: drop the sleep_ms argument · 7768d7d9
      Peter Hutterer authored
      This forces events for every ~10ms now. If we want a slower movement, we need
      more steps - just like a real touchpad does it.
      
      Cocinelle spatch files were variants of:
      	@@
      	expression A, B, C, D, E, F, G, H, I, J, K;
      	@@
      
      	- litest_touch_move_two_touches(A, B, C, D, E, F, G, H, I)
      	+ litest_touch_move_two_touches(A, B, C, D, E, F, G, H)
      
      The only test that needed a real fix was touchpad_no_palm_detect_2fg_scroll,
      it used 12ms before, now it's using 10ms so on the bcm5974 touchpad the second
      finger was a speed-thumb. Increasing the events and thus slowing down the
      pointer means it's a normal finger and the test succeeds again.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      7768d7d9
  2. 27 Aug, 2018 1 commit
  3. 06 Aug, 2018 1 commit
  4. 08 Jun, 2018 1 commit
  5. 18 Apr, 2018 1 commit
  6. 23 Mar, 2018 1 commit
  7. 21 Feb, 2018 1 commit
    • Peter Hutterer's avatar
      touchpad: delay arbitration by 90ms after touch toggle · 2a378bea
      Peter Hutterer authored
      When drawing on a tablet, the hand usually rests on the device, causing touch
      events. The kernel arbitrates for us in most cases, so we get a touch up
      and no events while the stylus is in proximity. When lifting the hand off in a
      natural position, the hand still touches the device when the pen goes out of
      proximity. This is 'immediately' followed by the hand lifting off the device.
      
      When kernel pen/touch arbitration is active, the pen proximity out causes a
      touch begin for the hand still on the pad. This is followed by a touch up when
      the hand lifts which happens to look exactly like a tap-to-click.
      
      Fix this by delaying the 'arbitration is now off' toggle, causing any touch
      that starts immediately after proximity out to be detected as palm and
      ignored for its lifetime.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=104985Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      2a378bea
  8. 13 Feb, 2018 3 commits
  9. 07 Feb, 2018 1 commit
  10. 08 Dec, 2017 1 commit
  11. 30 Nov, 2017 1 commit
  12. 21 Nov, 2017 1 commit
  13. 21 Sep, 2017 1 commit
  14. 19 Sep, 2017 2 commits
  15. 10 Jul, 2017 1 commit
  16. 04 May, 2017 1 commit
  17. 23 Mar, 2017 1 commit
  18. 14 Mar, 2017 1 commit
  19. 22 Feb, 2017 1 commit
  20. 09 Feb, 2017 1 commit
  21. 01 Feb, 2017 1 commit
  22. 20 Jan, 2017 5 commits
  23. 16 Jan, 2017 1 commit
  24. 15 Jan, 2017 2 commits
  25. 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
      it.
      
      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>
      b519ea4a
  26. 01 Sep, 2016 2 commits
  27. 02 Aug, 2016 2 commits
  28. 30 May, 2016 1 commit
    • Peter Hutterer's avatar
      tablet: up the reference count for the tool in the event · cf707baa
      Peter Hutterer authored
      Make sure that the tool is valid while the event is valid, even if the device
      gets destroyed before the event is destroyed.
      
      This cannot actually be triggered right now, the event has a ref to the device
      and the tools do not get removed until the device is destroyed. But for future
      implementations (e.g. where the tool is otherwise automatically destroyed on
      proximity out) we need to ensure the tool remains valid for the event
      lifetime.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      cf707baa
  29. 27 Apr, 2016 1 commit
  30. 11 Apr, 2016 1 commit