1. 28 Aug, 2018 5 commits
  2. 27 Aug, 2018 3 commits
  3. 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:
      libinput/libinput#80
      libinput/libinput#36Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      eca2f8c9
  4. 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>
      13bda5ad
  5. 08 Aug, 2018 1 commit
  6. 07 Aug, 2018 2 commits
  7. 03 Aug, 2018 1 commit
  8. 26 Jul, 2018 1 commit
  9. 26 Jun, 2018 1 commit
  10. 18 May, 2018 1 commit
  11. 10 May, 2018 1 commit
  12. 19 Apr, 2018 1 commit
  13. 05 Apr, 2018 1 commit
    • Peter Hutterer's avatar
      touchpad: don't process state for a touch in TOUCH_NONE · 928bad91
      Peter Hutterer authored
      If a touch is in TOUCH_NONE, there is nothing to see here, please move along.
      
      In the case of bug 105696, we were accessing the speed.exceeded_count of a
      touch that was released previously, erroneously detecting a speed-based thumb.
      The sequence was:
      - touch down in slot 0, speed.exceeded_count is reset to 0
      - move touch until exceeded_count is greater than our threshold
      - touch up in slot 0
      - touch down in slot 1 [1]
      - touch down in slot 2 (more than 25mm away)
      - we counted the slot 0 speed.exceeded_count, labeling the slot 2 touch as
        speed-based thumb
      
      [1] peculiar behavior only observed on this device, usually slots get re-used
      at the first opportunity so having an inactive slot followed by higher slots
      being used is unusual.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=105696Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      928bad91
  14. 23 Mar, 2018 1 commit
  15. 21 Mar, 2018 1 commit
    • Peter Hutterer's avatar
      touchpad: only keep low-pressure fingers alive for 2+-slot touchpads · 3f5ff113
      Peter Hutterer authored
      Regression introduced by 3979b9e1, bug 105258.
      With that commit, we only ended real touches when we had less than nslots fake
      fingers down. i.e. tripletap on a 2 slot touchpad would not end the
      first/second touch even if the pressure goes below the threshold. e.g. Lenovo
      x270 needs this, see https://bugs.freedesktop.org/attachment.cgi?id=137672, it
      dips below the pressure threshold for the first slot and ends the second slot
      in the same frame as the third finger is detected. Fun times.
      
      Anyway, this breaks semi-mt touchpads, another fine category of devices,
      because some of those can detect hovering fingers at low pressure, see bug
      105535. Because semi-mt devices are generally garbage, we treat them as
      single-touch devices instead. So whenever two fingers are down, we treat both
      as above the pressure threshold, even when they're physicall hovering.
      
      Fix this by making the x270 fix conditional on at least 2 slots.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=105535Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      3f5ff113
  16. 13 Mar, 2018 1 commit
  17. 01 Mar, 2018 2 commits
    • Peter Hutterer's avatar
      touchpad: add a TOUCH_MAYBE_END state · 6ccd8e93
      Peter Hutterer authored
      This state is used by the pre-processing of the touch states to indicate that
      the touch point has ended and is changed to TOUCH_END as soon as that
      pre-processing is finished.
      
      Sometimes we have to resurrect a touch point that has physically or logically
      ended but needs to be kept around to keep the BTN_TOOL_* fake finger count
      happy. Particularly on Synaptics touchpads, where a BTN_TOOL_TRIPLETAP can
      cause a touch point to end (i.e. 1 touch down + TRIPLETAP) but that touch
      restarts in the next sequence. We had a quirk for this in place already, but
      if we end the touch and then re-instate it with tp_begin_touch(), we may lose
      some information about thumb/palm/etc. states that touch already had. As a
      result, the state machines can get confused and a touch that was previously
      ignored as thumb suddenly isn't one anymore and triggers assertions.
      
      The specific sequence in bug 10528 is:
      * touch T1 down
      * touch T2 down, detected as speed-based thumb, tap state machine ignores
        it
      * frame F: TRIPLETAP down, touch T2 up
      * frame F+1: touch T2 down in next frame, but without the thumb bit
      * frame F+n: touch T2 ends, tap state machine gets confused because
        that touch should not trigger a release
      
      https://bugs.freedesktop.org/show_bug.cgi?id=105258Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      6ccd8e93
    • Peter Hutterer's avatar
      test: don't run the 2fg pressure test on single-touch touchpads · 21b83dfd
      Peter Hutterer authored
      Only the appletouch has pressure and thus executed that code path
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      21b83dfd
  18. 09 Jan, 2018 1 commit
  19. 20 Nov, 2017 1 commit
  20. 19 Nov, 2017 1 commit
  21. 31 Oct, 2017 1 commit
  22. 01 Sep, 2017 2 commits
  23. 11 Jul, 2017 3 commits
  24. 10 Jul, 2017 1 commit
  25. 09 Jul, 2017 1 commit
  26. 06 Jul, 2017 2 commits
  27. 05 Jul, 2017 1 commit
    • Peter Hutterer's avatar
      test: remove failing thumb edge scroll test · a31e4b81
      Peter Hutterer authored
      Broken since the merge of palm pressure detection in
      25d54b90, not sure why the test suite succeeded on that one nonetheless.
      
      I'm not 100% sure why the test does what it does but it seems to be testing
      that a wide touch on the side still striggers edge scrolling and not the thumb
      detection on the bottom of the touchpad. That is obsolete now, it's hard to
      generically figure out the small gap between thumb and palm pressure, so this
      test almost always triggers palm detection. It's obsolete.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      a31e4b81
  28. 03 Jul, 2017 1 commit
    • Peter Hutterer's avatar
      touchpad: add pressure-base palm detection · 25d54b90
      Peter Hutterer authored
      If a touch goes past the fixed pressure threshold it is labelled as a palm and
      stays a palm. Default value is one that works well here on a T440 and is
      virtually impossible to trigger by a normal finger or thumb. A udev property
      is exposed so we can handle this in the udev hwdb and the new tool introduce a
      few commits ago can help finding the palm detection threshold.
      
      Unlike the other palm detection features, once a palm goes past the threshold
      it remains a palm until the touch is released. This means palm overrides any
      other palm detection features. For code simplicity, we don't combine the
      states but merely check for pressure before and after the other palm detection
      functions. If the pressure triggers, it will trigger before anything else. And
      if something else is already active (e.g. edge where the pressure doesn't work
      well) it will trigger as soon as the palm is released.
      
      The palm threshold should thus be chosen with some room to spare between the
      highest finger pressure.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=94236Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      25d54b90