1. 03 Jun, 2020 1 commit
  2. 24 Feb, 2020 2 commits
  3. 18 Feb, 2020 2 commits
    • Peter Hutterer's avatar
      touchpad: sync the initial tracking id state to the touchpad · 06591e59
      Peter Hutterer authored
      Where fingers are down during startup we need to sync them to the known state
      of the device so our slot count is correct. Otherwise, when the fingers are
      lifted we will trigger the new assert for nactive_slots being less than 0.
      
      Regression introduced in eb6ef9fe
      
      Fixes #429Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      06591e59
    • Peter Hutterer's avatar
      touchpad: never reduce the slot count to 0 · 1e1b9c0e
      Peter Hutterer authored
      Where a user releases all touches during a SYN_DROPPED and then puts more than
      one finger back down before we sync, we end up with nonzero fake touches but
      a zero slot count. This is caused by a wrong event sequences provided by
      libevdev in that case.
      
      This really needs to be fixed in libevdev, see
      libevdev/libevdev!19
      
      In the meantime, put a check in to ignore that case and never reduce the slot
      count to 0. It still leaves us open for some issues where 3fg gestures may
      stop working if the right sequences are triggered during SYN_DROPPED but
      updating libevdev will eventually make that go away too.
      
      Fixes #422Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      1e1b9c0e
  4. 15 Nov, 2019 1 commit
  5. 14 Oct, 2019 1 commit
    • Peter Hutterer's avatar
      touchpad: use the same speed for scrolling as the baseline of the accel curve · 2b33445b
      Peter Hutterer authored
      Scrolling and gestures use unaccelerated motion. The idea behind it was that
      at least for the default speed setting of 0, the accelerated speed and
      unaccelerated speed are identical where meaningful.
      
      The touchpad speed curve has a plateau for 'normal' speeds (i.e. not very slow
      and not very fast) where the acceleration factor is constant. This is the
      reference factor that the unaccelerated motion should use as well.
      
      Since the touchpad acceleration rework in d6e53134 the reference factor is
      0.9 * TP_MAGIC_SLOWDOWN (previously the factor was 1.0 * TP_MAGIC_SLOWDOWN)
      and scroll motion is thus 10% faster than the pointer movement at the default
      speeds. Let's fix this and let the two match up.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      2b33445b
  6. 16 Jul, 2019 1 commit
    • Matt Mayfield's avatar
      touchpad: revamp thumb detection · 4536b5b3
      Matt Mayfield authored
      Instead of a simple yes/no/maybe for thumbs, have a more extensive state
      machine that keeps track of the thumb. Since we only support one thumb anyway,
      the tracking moves to the tp_dispatch struct.
      
      Test case changes:
      touchpad_clickfinger_3fg_tool_position:
        with better thumb detection we can now handle this properly and expect a
        right button (2fg) press for the test case
      touchpad_thumb_no_doublethumb_with_timeout:
        two thumbs are now always two fingers, so let's switch to axis events here
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      4536b5b3
  7. 15 Jul, 2019 3 commits
  8. 27 Jun, 2019 1 commit
    • Peter Hutterer's avatar
      evdev: when the kernel fuzz is nonzero, set ours to zero · 8d3788fa
      Peter Hutterer authored
      Our udev callout is supposed to reset the kernel fuzz to 0 and move the value
      to the LIBINPUT_FUZZ property. This is to stop the kernel from applying its
      own hysteresis-like approach.
      
      Where the kernel fuzz is nonzero, something has gone wrong with that approach.
      Complain about it and set our fuzz to zero, we are in the hands of the kernel
      now. If we leave our fuzz as nonzero, we'll apply our own hysteresis on top of
      the kernel's and that leads to unresponsive behavior.
      
      Fixes #313Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      8d3788fa
  9. 24 Jun, 2019 1 commit
    • Peter Hutterer's avatar
      test: fix the slot swap test again · 015af5f3
      Peter Hutterer authored
      The previous movement was one finger still, the second finger moving. This may
      cause axis events to trigger when a 2fg scroll gesture was detected. Those
      axis events will stop after the gesture timeout but generate one more axis
      stop event.
      
      Make two changes here: first, move the fingers like a proper 2fg scroll
      motion. And shuffle around the litest_drain_events() calls to ignore any axis
      event immediately after the timeout.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      015af5f3
  10. 20 Jun, 2019 5 commits
  11. 19 Jun, 2019 1 commit
  12. 18 Jun, 2019 3 commits
  13. 11 Jun, 2019 1 commit
    • Peter Hutterer's avatar
      test: fix an intermitted failing test · 164a6a81
      Peter Hutterer authored
      The touchpad_2fg_scroll_initially_diagonal test would semi-reliably fail under
      valgrind but succeed otherwise. Cause was that on some devices, the initial
      diagonal movement wasn't diagonal enough and closer to a horizontal movement.
      This was fine on normal runs, but under valgrind we'd hit the "active
      threshold" time limit and lock to horizontal scrolling, ditching the remaining
      events and failing the test.
      
      Fix this by calculating the scroll vector based on the device's width/height
      ratio and go "more diagonal" on the initial vector.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      164a6a81
  14. 27 May, 2019 1 commit
  15. 30 Apr, 2019 1 commit
    • Peter Hutterer's avatar
      touchpad: rotate the touch part of tablets · 6229df18
      Peter Hutterer authored
      Tablets in left-handed mode are rotated, so we need to rotate the touchpad
      part of them too. This doesn't affect all tablets though, some of them are
      symmetrical and the left-handed mode merely changes the button order around
      (some of the earlier Bamboos). So we rely on libwacom to tell us which device
      must be rotated.
      
      The rotation itself is done on the input coordinate itself as we get it. This
      way any software buttons, palm zones, etc. are automatically handled by rest
      of the code.
      
      Fixes #274Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      6229df18
  16. 14 Feb, 2019 1 commit
  17. 29 Jan, 2019 1 commit
  18. 15 Oct, 2018 1 commit
    • Peter Hutterer's avatar
      touchpad: handle a touch ending and restarting in the same frame · 12dc64af
      Peter Hutterer authored
      If a touch ends and starts again in the same frame, our touch count gets out
      of whack. This later triggers an assertion when the tap touch count mismatches
      the real tap count.
      
      E: 0.105005 0003 0039 -001      # EV_ABS / ABS_MT_TRACKING_ID   -1
      E: 0.105005 0003 0035 8447      # EV_ABS / ABS_MT_POSITION_X    8447
      E: 0.105005 0003 0036 4479      # EV_ABS / ABS_MT_POSITION_Y    4479
      E: 0.105005 0001 014a 0000      # EV_KEY / BTN_TOUCH            0
      E: 0.105005 0001 0145 0000      # EV_KEY / BTN_TOOL_FINGER      0
      E: 0.105005 0003 0039 0074      # EV_ABS / ABS_MT_TRACKING_ID   74
      E: 0.105005 0003 0035 8388      # EV_ABS / ABS_MT_POSITION_X    8388
      E: 0.105005 0003 0036 4480      # EV_ABS / ABS_MT_POSITION_Y    4480
      E: 0.105005 0001 014a 0001      # EV_KEY / BTN_TOUCH            1
      E: 0.105005 0001 0145 0001      # EV_KEY / BTN_TOOL_FINGER      1
      E: 0.105005 0003 0000 8388      # EV_ABS / ABS_X                8388
      E: 0.105005 0003 0001 4480      # EV_ABS / ABS_Y                4480
      E: 0.105005 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +19ms
      
      This is a kernel bug but let's paper over here because otherwise we crash and
      that's considered impolite.
      
      Fixes #161Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      12dc64af
  19. 04 Oct, 2018 1 commit
    • Peter Hutterer's avatar
      touchpad: avoid motion events when moving one finger into AREA · df1f6ba4
      Peter Hutterer authored
      If a 2fg scroll motion starts with both fingers in the bottom button area and
      one finger moves into the main area before the other, we used to send motion
      events for that finger. Once the second finger moved into the main area the
      scroll was detected correctly but by then the cursor may have moved out of the
      intended focus area.
      
      We have two transitions where we may start sending motion events: when we move
      out of the bottom area and when the finger moves by more than 5mm within the
      button area. In both cases, check for any touches that are in the
      bottom area and started at the 'same' time as our moving touch. Mark those as
      'moved' to release them for gestures so we get the right finger count and
      axis/gesture events instead of just motion events.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      df1f6ba4
  20. 03 Oct, 2018 1 commit
  21. 02 Oct, 2018 1 commit
    • Peter Hutterer's avatar
      touchpad: ignore motion speed for hovering touches · a8e3f4d1
      Peter Hutterer authored
      tp_detect_thumb_while_moving() assumes that of the 2 fingers down, at least
      one must be in TOUCH_UPDATE, otherwise we wouldn't have a speed to analyze for
      thumb.
      
      If a touch starts in HOVERING and exceeds the speed limit, we were previously
      increasing the 'exceeded count'. This later leads to an assert() in
      tp_detect_thumb_while_moving() when the second finger comes down because
      although we have multiple fingers, none of them are in TOUCH_UPDATE.
      
      This only happens when fingers 2 and 3 come down in the same event frame,
      because then we have nfingers_down at 2 (the hovering one doesn't count) but
      we don't yet have a finger in TOUCH_UPDATE.
      
      Fix this twofold, first by now calculating the speed on anything but
      TOUCH_UPDATE. And second by force-resetting the speed count on
      TOUCH_BEGIN/TOUCH_END so we definitely cover all the hover transitions.
      
      Fixes #150Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      a8e3f4d1
  22. 28 Aug, 2018 7 commits
  23. 27 Aug, 2018 2 commits