Skip to content

GitLab

Switch branch/tag
  1. 05 Sep, 2014 2 commits
  3. 03 Sep, 2014 1 commit
    • Peter Hutterer's avatar
      eventcomm: ensure we're on the same clock as the server · 90d19302
      Peter Hutterer authored 
      Default on evdev devices is CLOCK_REALTIME. If that clock falls behind the
server's CLOCK_MONOTONIC, motion after a clickpad click may be delayed by the
difference in the clocks.

In detail:
When the timer func is triggered, GetTimeInMillis() which is CLOCK_MONOTONIC,
is stored as hwState->millis. The eventcomm backend uses struct
input_event time (CLOCK_REALTIME).

When we read events from the device, if the evdev time is less than the server
time, the fix for (#48777) sets the current event time to hwState->millis.
Until the evdev time overtakes that stored time, all events have the
hwState->millis time.

If during that time a clickpad triggers a physical click,
clickpad_click_millis is set to hwState->millis + the ignore-motion timeout.
Thus, all motion is ignored until the event time overtakes that stored
time.

The whole issue is further enhanced by us unconditionally setting the timer
func if we get any events, which is a separate issue anyway.
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      90d19302
  5. 28 Aug, 2014 2 commits
  7. 14 Aug, 2014 1 commit
  9. 08 Aug, 2014 3 commits
  11. 20 May, 2014 1 commit
  13. 13 May, 2014 1 commit
  15. 30 Apr, 2014 4 commits
  17. 29 Apr, 2014 1 commit
  19. 22 Apr, 2014 2 commits
  21. 09 Apr, 2014 4 commits
  23. 23 Mar, 2014 1 commit
    • Peter Hutterer's avatar
      Disable GrabEventDevice by default · f1948e08
      Peter Hutterer authored 
      This was required when we started supporting hotplugging to avoid duplicate
events. These days the drawback of not being able to record events in the case
of a bug is significant.

Check the configuration source on init. If the device was hotplugged through a
a server config backend, disable the grab. If the device was statically
configured through an xorg.conf then leave the default grab enabled to avoid
a duplicate device.
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      f1948e08
  25. 17 Mar, 2014 2 commits
  27. 14 Mar, 2014 1 commit
  29. 13 Mar, 2014 2 commits
  31. 12 Mar, 2014 4 commits
  33. 11 Mar, 2014 6 commits
  35. 26 Feb, 2014 2 commits
    • Peter Hutterer's avatar
      man: fix documentation about the new touchpad state · c431d900
      Peter Hutterer authored 
      leftover from an earlier revision
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      c431d900
    • Hans de Goede's avatar
      Wait for *new* coordinates on a clickpad click before reporting the click · bbe4c56c
      Hans de Goede authored 
      It is possible for a click to get reported before any related touch events
get reported, here is the relevant part of an evemu-record session on a T440s:

E: 3.985585 0000 0000 0000	# ------------ SYN_REPORT (0) ----------
E: 3.997419 0003 0039 -001	# EV_ABS / ABS_MT_TRACKING_ID   -1
E: 3.997419 0001 014a 0000	# EV_KEY / BTN_TOUCH            0
E: 3.997419 0003 0018 0000	# EV_ABS / ABS_PRESSURE         0
E: 3.997419 0001 0145 0000	# EV_KEY / BTN_TOOL_FINGER      0
E: 3.997419 0000 0000 0000	# ------------ SYN_REPORT (0) ----------
E: 5.117881 0001 0110 0001	# EV_KEY / BTN_LEFT             1
E: 5.117881 0000 0000 0000	# ------------ SYN_REPORT (0) ----------
E: 5.133422 0003 0039 0187	# EV_ABS / ABS_MT_TRACKING_ID   187
E: 5.133422 0003 0035 3098	# EV_ABS / ABS_MT_POSITION_X    3098
E: 5.133422 0003 0036 3282	# EV_ABS / ABS_MT_POSITION_Y    3282
E: 5.133422 0003 003a 0046	# EV_ABS / ABS_MT_PRESSURE      46
E: 5.133422 0001 014a 0001	# EV_KEY / BTN_TOUCH            1
E: 5.133422 0003 0000 3102	# EV_ABS / ABS_X                3102
E: 5.133422 0003 0001 3282	# EV_ABS / ABS_Y                3282
E: 5.133422 0003 0018 0046	# EV_ABS / ABS_PRESSURE         46
E: 5.133422 0001 0145 0001	# EV_KEY / BTN_TOOL_FINGER      1
E: 5.133422 0000 0000 0000	# ------------ SYN_REPORT (0) ----------

Notice the BTN_LEFT event all by itself!

If this happens, it may lead to the following problem scenario:
-touch the touchpad in its right click area
-let go of the touchpad
-rapidly click in the middle area, so that BTN_LEFT gets reported before the
 new coordinates (such as seen in the trace above, this may require some
 practicing with evemu-record to reproduce)
-the driver registers the click as a right click because it uses the
 old coordinates from the cumulative coordinates to determine the
 click location

This commit fixes this by:
1) Resetting the cumulative coordinates not only when no button is pressed,
   but also when there is no finger touching the touchpad, so that when
   we do get a touch the cumulative coordinates start at the right place
2) Delaying processing the BTN_LEFT down transition if there is no finger
   touching the touchpad

This approach has one downside, if we wrongly identify a touchpad as
a clickpad, then the left button won't work unless the user touches the
touchpad while clicking the left button.

If we want we can fix this by doing something like this:
1) Making update_hw_button_state return a delay; and
2) Tracking that we've delayed BTN_LEFT down transition processing; and
3) When we've delayed BTN_LEFT down transition return a small delay value; and
4) If when we're called again we still don't have a finger down, just
   treat the click as a BTN_LEFT

But this is not worth the trouble IMHO, the proper thing to do in this
scenario is to fix the mis-identification of the touchpad as a clickpad.
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      bbe4c56c