1. 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>
  2. 07 Jan, 2015 1 commit
  3. 17 Sep, 2014 2 commits
    • Gabriele Mazzotta's avatar
      Use ABS_MT events for the palm detection when supported · a897147b
      Gabriele Mazzotta authored
      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: default 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>
  4. 16 Sep, 2014 1 commit
  5. 05 Sep, 2014 3 commits
  6. 14 Aug, 2014 1 commit
  7. 30 Apr, 2014 1 commit
    • Hans de Goede's avatar
      Add support for INPUT_PROP_TOPBUTTONPAD · 7bf27568
      Hans de Goede authored
      Add a HasSecondaryButtons boolean config option which defaults to true for
      devices with the INPUT_PROP_TOPBUTTONPAD and false for all other devices.
      Only parse the SecondarySoftButtonAreas when this option is true, effectively
      disabling the top buttons when it is false. Likewise, only initialize the
      SecondarySoftButtonAreas property if we enable support for it.
      This means that it is now safe to always set a SecondarySoftButtonAreas
      default in 50-synaptics.conf, and that he section which was intended for
      use with future pnp-id matching can be dropped, as that is now all handled
      in the kernel.
      While at also remove the comment about disabling the bottom edge area, as that
      is now done automatically.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
  8. 22 Apr, 2014 1 commit
  9. 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>
  10. 17 Mar, 2014 1 commit
  11. 12 Mar, 2014 3 commits
  12. 11 Mar, 2014 2 commits
  13. 26 Feb, 2014 5 commits
    • 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>
    • Hans de Goede's avatar
      Ignore motion the first X ms after a clickpad click · 71652fe1
      Hans de Goede authored
      This fixes my #1 anoyance with clickpads, where 2 out of 3 clicks turn into
      a click + drag unless I hold my finger really really still.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Replaced property with a hardcoded 100ms. This is not something that we should
      expose as property, we should find a delay that works best and live with it.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Hans de Goede's avatar
      Don't report motion inside soft-button areas · 3adaf462
      Hans de Goede authored
      Unless the motion has started outside the soft-button area.
      Note that we must start reporting motions regardless of whether we think we're
      in the button area or not as soon as we've switched to using cumulative
      coordinates, since then the coordinates are no longer absolute.
      This fixes the reporting of unintended motion just before a click in a soft
      button area which sometimes causes mis-clicks.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Hans de Goede's avatar
      Get rid of old_hw_state · effeee86
      Hans de Goede authored
      We only use it to store button state which we already have in
      While at it also properly indent the code block checking the various
      soft button areas.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Hans de Goede's avatar
      Add an enum for the different soft_button_areas · 84067050
      Hans de Goede authored
      While at it also move the enum for the soft button edges out of
      is_inside_button_area() so that it can be used elsewhere too.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  14. 23 Feb, 2014 2 commits
  15. 21 Feb, 2014 1 commit
  16. 20 Feb, 2014 1 commit
  17. 17 Feb, 2014 1 commit
  18. 16 Jan, 2014 1 commit
    • Peter Hutterer's avatar
      Revert "Purge scrollbuttons (repeat)" · e0069c15
      Peter Hutterer authored
      This reverts commit 0903d99a.
      Scroll buttons are still present in some modern devices, e.g. the Fujitsu
      Lifebook E782 and others in the series.
  19. 06 Jan, 2014 1 commit
  20. 06 Nov, 2013 1 commit
  21. 19 Jul, 2013 1 commit
  22. 09 May, 2013 2 commits
  23. 26 Apr, 2013 1 commit
  24. 05 Apr, 2013 2 commits
  25. 30 Jan, 2013 1 commit
  26. 21 Dec, 2012 1 commit
  27. 30 Aug, 2012 1 commit