1. 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>
  2. 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>
  3. 20 Jun, 2019 5 commits
  4. 19 Jun, 2019 1 commit
  5. 18 Jun, 2019 3 commits
  6. 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>
  7. 27 May, 2019 1 commit
  8. 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>
  9. 14 Feb, 2019 1 commit
  10. 29 Jan, 2019 1 commit
  11. 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>
  12. 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>
  13. 03 Oct, 2018 1 commit
  14. 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
      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>
  15. 28 Aug, 2018 7 commits
  16. 27 Aug, 2018 3 commits
  17. 20 Aug, 2018 1 commit
    • Peter Hutterer's avatar
      touchpad: improve pointer jump detection · eca2f8c9
      Peter Hutterer authored
      Previously, we had a hard threshold of 20mm per event frame. That is just
      about achievable by really fast movements (in which case you don't care too
      much about the jumps anyway because you've already hit the edge of the screen).
      Sometimes pointer jumps have lower deltas that are achievable even on slower,
      more likely motions. Analysis of finger motion has shown that while a delta
      >7mm per event is possible, jumping _by_ 7mm between two events is unlikely
      and indicates a pointer jump. So let's diff the most recent delta and the
      current delta, if it increases by 7mm between two event frames let's say it's
      a pointer jump and discard it.
      Helps with but does not fully resolve:
      #36Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  18. 13 Aug, 2018 1 commit
    • Peter Hutterer's avatar
      touchpad: if a finger in the button area moves by more than 5mm, release it · 13bda5ad
      Peter Hutterer authored
      The software button area is currently a partially-dead area. If the finger
      moves into or out of the area pointer motion works. Finger motion within the
      area however does not generate motion.
      The main motivation for this was to avoid accidental pointer motion when a
      button is pressed. This is required for stationary fingers but once you move a
      significant distance, those bets are off.
      So if the finger moves by more than 5mm from where it was put down, release it
      and let it move the pointer.
      The full impact is largely limited to horizontal movements within the button
      area because:
      - leaving the finger at the bottom area for 300ms without movement triggers
        the thumb identification, so it won't move anyway.
      - moving the finger north is likely to go off the button area before we
        trigger this threshold.
      #86Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  19. 08 Aug, 2018 1 commit
  20. 07 Aug, 2018 2 commits
  21. 03 Aug, 2018 1 commit
  22. 26 Jul, 2018 1 commit
  23. 26 Jun, 2018 1 commit
  24. 18 May, 2018 1 commit
  25. 10 May, 2018 1 commit