1. 22 May, 2020 1 commit
    • Matt Mayfield's avatar
      touchpad: restore thumb detection while keeping fixes from !292 · 73870d93
      Matt Mayfield authored
      !292 improved libinput's ability to detect multiple-finger clicks when
      the fingers were not aligned close to horizontally. However that caused
      thumb detection to fail in several use cases.
      
      This patch restores thumb detection for
      - 2+ finger physical clickpad presses
      - resting thumb while two-finger scrolling
      - touches in the thumb exclusion area during multi-finger taps
      and improves pinch detection when thumb is centered below fingers.
      
      It also further enhances the flexibility of finger position for 2-, 3-,
      or 4-finger taps: if all tapping fingers land on the touchpad within a
      short time (currently 100ms), they will all count regardless of
      position (unless below the lower_thumb_line).
      Signed-off-by: Matt Mayfield's avatarMatt Mayfield <mdmayfield@yahoo.com>
      73870d93
  2. 21 Mar, 2020 1 commit
  3. 29 Jan, 2020 1 commit
    • Peter Hutterer's avatar
      touchpad: correct a wrong slot count by the kernel · eb6ef9fe
      Peter Hutterer authored
      alps.c hardcodes 5 slots in the kernel but some devices only provide 2 slots
      plus BTN_TOOL_TRIPLETAP, etc. Fix this by counting active slots and when the
      fake finger count exceeds the active slots but is still less than the number
      of slots, adjust the slots themselves downwards.
      
      And because the new test device messes with our slot count assumptions for the
      various tests hardcode that one device to return 2 slots.
      
      Fixes #408Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      eb6ef9fe
  4. 26 Nov, 2019 1 commit
  5. 11 Sep, 2019 1 commit
  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 8 commits
  8. 27 May, 2019 1 commit
    • Peter Hutterer's avatar
      touchpad: lock the touchpad rotation to the tablet rotation · e8bf179f
      Peter Hutterer authored
      Follow-up to 6229df18
      We must not rely on the caller to toggle the left-handed bits correctly since
      they may not know which devices belong together (despite device groups). Let's
      do the right thing here, if the tablet is set to left-handed, rotate the
      touchpad accordingly.
      
      Note that the left-handed setting of the tablet is left as-is
      (right-handed). Until we have notifications about configuration changes, this
      is the best we can do.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      e8bf179f
  9. 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
  10. 11 Feb, 2019 1 commit
  11. 31 Jan, 2019 1 commit
  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>
      df1f6ba4
  13. 31 Aug, 2018 1 commit
    • Peter Hutterer's avatar
      touchpad: add timestamp-based jump detection · 1f5c0119
      Peter Hutterer authored
      On Dell i2c touchpads, the controller appears to go to sleep after about 1s of
      inactivity on the touchpad. The wakeup takes a while so on the next touch, we
      may see a pointer jump, specifially on the third event (i.e. touch down,
      event, event+jump). The MSC_TIMESTAMP value carries a hint for what's
      happening here, the event sequence for a touchpad with scanout intervals
      7300µs is:
      
      	...
      	MSC_TIMESTAMP 0
      	SYN_REPORT
      	...
      	MSC_TIMESTAMP 7300
      	SYN_REPORT +2ms
      	...
      	MSC_TIMESTAMP 123456
      	SYN_REPORT +7ms
      	...
      	MSC_TIMESTAMP 123456+7300
      	SYN_REPORT +8ms
      
      Note how the SYN_REPORT timestamps don't reflect the MSC_TIMESTAMPS.
      
      This patch adds a quirk activate MSC_TIMESTAMP watching. When we do so, we
      monitor for a 0 MSC_TIMESTAMP. Let's assume that the first event after that is
      the interval, then check the third event. If that third event's timestamp is too
      large rewrite the touches' motion history to reflect the correct timestamps,
      i.e. instead of the SYN_REPORT timestamps the motion history now uses
      "third-event SYN_REPORT timestamps minus MSC_TIMESTAMP values".
      
      The pointer accel filter code uses absolute timestamps (#123) so we have to
      restart the pointer acceleration filter when we detect this jump. This allows
      us to reset the 0 time for the filter to the previous event's MSC_TIMESTAMP
      time, so that our new large delta has the correct time delta too. This
      calculates the acceleration correctly for that window.
      
      The result is that the pointer is still delayed by the wake-up window (not
      fixable in libinput) but at least it ends up where it should've.
      
      There are a few side-effects: thumb, gesture, and hysteresis all still use the
      unmodified SYN_REPORT time. There is a potential for false detection of either
      of these now, but we'll have to fix those as they come up.
      
      Fixes #36Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      1f5c0119
  14. 29 Aug, 2018 2 commits
  15. 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:
      #80
      #36Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      eca2f8c9
  16. 13 Aug, 2018 2 commits
    • 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
    • Peter Hutterer's avatar
      touchpad: rename 'curr' to 'current' · 9d06f347
      Peter Hutterer authored
      We can affort the extra 3 bytes storage.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      9d06f347
  17. 08 Aug, 2018 1 commit
    • Matt Mayfield's avatar
      touchpad: 90-degree scroll helper · bb87a3d9
      Matt Mayfield authored
      This makes two-finger scrolling in straight lines easier, while still
      allowing free/diagonal movement. It works in three stages:
      
      1) Initial movement
         - For the first few millimeters, scroll movements within 30 degrees
           of horizontal or vertical are straightened to 90-degree angles.
         - Scroll movements close to 45 degree diagonals are unchanged.
         - If movement continues very close to straight horizontal or
           vertical, stage 2 begins and the axis lock engages.
         - If movement continues along a diagonal, stage 2 is skipped and
           free scrolling is immediately enabled.
      2) Axis lock
         - If the user scrolls fairly closely to straight vertical, no
           horizontal movement will happen at all, and vice versa.
         - It is possible to switch between straight vertical and straight
           horizontal, and the axis lock will automatically change.
         - If deliberate diagonal movement is detected at any point, stage
           3 begins and the axis lock disengages.
      3) Free scrolling
         - Scrolling is unconstrained until the fingers are lifted.
      bb87a3d9
  18. 13 Jun, 2018 1 commit
  19. 29 May, 2018 1 commit
  20. 18 May, 2018 1 commit
  21. 01 Mar, 2018 3 commits
  22. 21 Feb, 2018 2 commits
    • 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
    • Peter Hutterer's avatar
      touchpad: change the stylus palm arbitration to process touches · da74aab7
      Peter Hutterer authored
      Previously, on touch toggle (invoked by the tablet when a pen goes in
      proximity) the touchpad cleared the state and ignored any events. Since we
      ignore touches that we didn't see the touch begin for, this handled the cases
      of a touch remaining after proximity out.
      
      This code pre-dates palm detection, so let's take the bluetack off and instead
      integrate it with proper palm detectino.
      da74aab7
  23. 20 Feb, 2018 1 commit
  24. 10 Jan, 2018 1 commit
    • Peter Hutterer's avatar
      touchpad: drop the double normalization · 937e6031
      Peter Hutterer authored
      Previously, touchpad deltas were converted to 1000-dpi normalized coordinates
      and handled from there. This changed in bdd4264d (1.6)
      when the filter functions started taking device coordinates instead. Since
      then, we used to convert the device delta to normalized coordinates, then
      (often immediately) convert back to device coordinates, albeit for equal x/y
      resolution. This isn't necessary, we can just convert the device coordinates
      to x/y-equal resolution device coordinates and pass those on.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      937e6031
  25. 20 Nov, 2017 1 commit
    • Peter Hutterer's avatar
      touchpad: work palm detection into the tap state machine · 46eab975
      Peter Hutterer authored
      Unlike the already-existing thumb detection, a touch may be labelled palm at
      any time, not just during the initial touch down. This requires full
      integration into the tap state machine to unwind properly. For most states, a
      palm detection simply ignores the finger and reverts to the most recent state.
      
      One exception is the case of two fingers down, one finger up followed by the
      remaining finger detected as a palm finger. This triggers a single-finger tap
      but with timestamps that may be from the wrong finger. Since we're within a
      short tap timeout anyway this should not matter too much.
      
      The special state PALM_UP is only handled in one condition (DEAD). Once a
      touch is a palm we basically skip over it from then on. If we end up in the
      DEAD state after a button press we still need to handle the palm up events
      accordingly to be able to return to IDLE. That transition also requires us to
      have an accurate count of the real fingers down (palms don't count) so we need
      a separate nfingers_down counter for tapping.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=103210Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      46eab975
  26. 31 Oct, 2017 1 commit
  27. 30 Oct, 2017 2 commits