1. 24 Mar, 2015 1 commit
  2. 17 Mar, 2015 1 commit
    • Peter Hutterer's avatar
      Revert "Support the new Lenovo X1 Carbon 3rd trackpoint buttons" · 5378a020
      Peter Hutterer authored
      This reverts commit 06444536.
      The Lenovo *50 series, including the X1 Carbon 3rd always require multiple
      kernel patches to enable the touchpad buttons. This patch in synaptics only
      addresses the re-routing of the top buttons.
      The final iteration of the kernel patches also route the trackpoint buttons
      through the trackpoint device, rendering this patch unnecessary. These patches
      are queued for 4.0.
      See kernel patch series up to commit cdd9dc195916ef5644cfac079094c3c1d1616e4c
      Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
      Date:   Sun Mar 8 22:35:41 2015 -0700
          Input: synaptics - re-route tracksticks buttons on the Lenovo 2015 series
      Currently in Dmitry's for-linus branch.
      Distributions running older kernels or the kernel stable series which has
      partial backports of the above patch series are encouraged to leave the
       commit in and undo this revert.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
  3. 06 Mar, 2015 1 commit
  4. 18 Feb, 2015 1 commit
  5. 29 Jan, 2015 1 commit
    • Peter Hutterer's avatar
      Support the new Lenovo X1 Carbon 3rd trackpoint buttons · 06444536
      Peter Hutterer authored
      This device has the trackpoint buttons wired up to the touchpad to send BTN_0,
      BTN_1 and BTN_2 for left, right, middle. This conflicts with previous
      touchpads that used those event codes for dedicated scroll buttons.
      Add an option HasTrackpointButtons that can be set via a xorg.conf.d
      snippets. This option is not intended as a user-set option, rather
      we expect distributions to ship some conglomerate of udev/hal rules with
      xorg.conf snippets that take effect.
      If the option is set, we look at the three affected buttons at the beginning
      of HandleState and send button events immediately for them. The HW state is
      reset to neutral and other processing continues. This saves us from having to
      synchronize these buttons with software buttons (also present on this device),
      tapping, etc.
      Since the buttons are physically different and (mentally) associated with the
      trackpoint device we also don't need to worry about having finger motion event
      correctly synced up with the button presses - it's acceptable to send the
      presses before the motion events.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Tested-by: Benjamin Tissoires's avatarBenjamin Tissoires <benjamin.tissoires@gmail.com>
  6. 16 Jan, 2015 1 commit
  7. 12 Jan, 2015 1 commit
  8. 07 Jan, 2015 1 commit
  9. 17 Sep, 2014 2 commits
    • Gabriele Mazzotta's avatar
      Use ABS_MT events for the palm detection when supported · a897147b
      Gabriele Mazzotta authored and Peter Hutterer's avatar Peter Hutterer committed
      and ABS_PRESSURE when supported so that the pressure and the width of
      all the fingers is taken into account for the palm detection.
      This also fixes the palm detection for those touchpads for which the
      kernel only sends ABS_MT_TOUCH_MAJOR and not ABS_TOOL_WIDTH.
      Signed-off-by: Gabriele Mazzotta's avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Peter Hutterer's avatar
      Limit the movement to 20 mm per event · 41b2312c
      Peter Hutterer authored
      Touchpads are limited by a fixed sampling rate (usually 80Hz). Some finger
      changes may happen too fast for this sampling rate, resulting in two distinct
      event sequences:
      * finger 1 up and finger 2 down in the same EV_SYN frame. Synaptics sees one
        finger down before and after and the changed coordinates
      * finger 1 up and finger 2 down _between_ two EV_SYN frames. Synaptics sees one
        touchpoint move from f1 position to f2 position.
      That move causes a large cursor jump. The former could be solved (with
      difficulty) by adding fake EV_SYN handling after releasing touchpoints but
      that won't fix the latter case.
      So as a solution for now limit the finger movement to 20mm per event.
      Tests on a T440 and an x220 showed that this is just above what a reasonable
      finger movement would trigger. If a movement is greater than that limit, reset
      it to 0/0.
      On devices without resolution, use 0.25 of the touchpad's diagonal instead.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
  10. 16 Sep, 2014 1 commit
  11. 05 Sep, 2014 5 commits
  12. 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
      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>
  13. 28 Aug, 2014 2 commits
  14. 14 Aug, 2014 1 commit
  15. 08 Aug, 2014 3 commits
  16. 20 May, 2014 1 commit
  17. 13 May, 2014 1 commit
  18. 30 Apr, 2014 4 commits
  19. 29 Apr, 2014 1 commit
  20. 22 Apr, 2014 2 commits
  21. 09 Apr, 2014 4 commits
  22. 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>
  23. 17 Mar, 2014 2 commits
  24. 14 Mar, 2014 1 commit