1. 27 5月, 2014 2 次提交
  2. 15 5月, 2014 1 次提交
  3. 24 4月, 2014 1 次提交
  4. 20 4月, 2014 2 次提交
  5. 29 3月, 2014 2 次提交
  6. 13 8月, 2013 1 次提交
  7. 05 6月, 2013 1 次提交
    • E
      Input: synaptics - fix sync lost after resume on some laptops · eeb06558
      Eric Miao 提交于
      In summary, the symptom is intermittent key events lost after resume
      on some machines with synaptics touchpad (seems this is synaptics _only_),
      and key events loss is due to serio port reconnect after psmouse sync lost.
      Removing psmouse and inserting it back during the suspend/resume process
      is able to work around the issue, so the difference between psmouse_connect()
      and psmouse_reconnect() is the key to the root cause of this problem.
      
      After comparing the two different paths, synaptics driver has its own
      implementation of synaptics_reconnect(), and the missing psmouse_probe()
      seems significant, the patch below added psmouse_probe() to the reconnect
      process, and has been verified many times that the issue could not be reliably
      reproduced.
      
      There are two PS/2 commands in psmouse_probe():
      
        1. PSMOUSE_CMD_GETID
        2. PSMOUSE_CMD_RESET_DIS
      
      Only the PSMOUSE_CMD_GETID seems to be significant. The
      PSMOUSE_CMD_RESET_DIS is irrelevant to this issue after trying
      several times.  So we have only implemented this patch to issue
      the PSMOUSE_CMD_GETID so far.
      Tested-by: NDaniel Manrique <daniel.manrique@canonical.com>
      Signed-off-by: NJames M Leddy <james.leddy@canonical.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      eeb06558
  8. 16 2月, 2013 1 次提交
  9. 14 2月, 2013 1 次提交
    • D
      Input: synaptics - fix 1->3 contact transition reporting · 48064bdc
      Daniel Kurtz 提交于
      Investigating the following gesture highlighted two slight implementation
      errors with choosing which slots to report in which slot when multiple
      contacts are present:
      
      Action                 SGM  AGM (MTB slot:Contact)
      1. Touch contact 0    (0:0)
      2. Touch contact 1    (0:0, 1:1)
      3. Lift  contact 0    (1:1)
      4. Touch contacts 2,3 (0:2, 1:3)
      
      In step 4, slot 1 was not being cleared first, which means the same
      tracking ID was being used for reporting both the old contact 1 and the
      new contact 3.  This could result in "drumroll", where the old contact 1
      would appear to suddenly jump to new finger 3 position.
      
      Similarly, if contacts 2 & 3 are not detected at the same sample, step 4
      is split into two:
      
      Action                SGM  AGM  (MTB slot:contact)
      1. Touch contact 0   (0:0)
      2. Touch contact 1   (0:0, 1:1)
      3. Lift  contact 0   (1:1)
      4. Touch contact 2   (0:2, 1:1)
      5. Touch contact 3   (0:2, 1:3)
      
      In this case, there was also a bug.  In step 4, when contact 1 moves from
      SGM to AGM and contact 2 is first reported in SGM, slot 0 was actually
      empty.  So slot 0 can be used to report the new SGM (contact 0),
      immediately.  Since it was empty, contact 2 in slot 0 will get a new
      tracking ID.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      48064bdc
  10. 29 9月, 2012 1 次提交
  11. 20 9月, 2012 1 次提交
  12. 25 7月, 2012 1 次提交
    • S
      Input: synaptics - handle out of bounds values from the hardware · c0394506
      Seth Forshee 提交于
      The touchpad on the Acer Aspire One D250 will report out of range values
      in the extreme lower portion of the touchpad. These appear as abrupt
      changes in the values reported by the hardware from very low values to
      very high values, which can cause unexpected vertical jumps in the
      position of the mouse pointer.
      
      What seems to be happening is that the value is wrapping to a two's
      compliment negative value of higher resolution than the 13-bit value
      reported by the hardware, with the high-order bits being truncated. This
      patch adds handling for these values by converting them to the
      appropriate negative values.
      
      The only tricky part about this is deciding when to treat a number as
      negative. It stands to reason that if out of range values can be
      reported on the low end then it could also happen on the high end, so
      not all out of range values should be treated as negative. The approach
      taken here is to split the difference between the maximum legitimate
      value for the axis and the maximum possible value that the hardware can
      report, treating values greater than this number as negative and all
      other values as positive. This can be tweaked later if hardware is found
      that operates outside of these parameters.
      
      BugLink: http://bugs.launchpad.net/bugs/1001251
      Cc: stable@vger.kernel.org
      Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
      Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      c0394506
  13. 08 7月, 2012 1 次提交
  14. 11 5月, 2012 1 次提交
  15. 21 4月, 2012 1 次提交
  16. 12 12月, 2011 1 次提交
  17. 16 11月, 2011 1 次提交
    • D
      Input: synaptics - update OLPC XO exclusion · 83551c01
      Daniel Drake 提交于
      We have determined that the jumpiness previously seen when using
      the synaptics kernel mouse driver on OLPC XO was due to not using
      the synaptics X11 userspace driver - the xf86-input-evdev driver was
      interpreting 'finger near pad' signals as movements. Newer versions
      of xf86-input-evdev fix this issue.
      
      Additionally, the synaptics kernel driver is now usable on this
      platform, but only when run in relative mode.
      
      Update the comment and refine the check to allow the synaptics driver
      to run on OLPC XO in relative mode.
      
      We will continue investigating the EC issue as time becomes available.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      83551c01
  18. 10 11月, 2011 1 次提交
    • D
      Input: synaptics - add support for Relative mode · 7968a5dd
      Daniel Drake 提交于
      Currently, the synaptics driver puts the device into Absolute mode.
      As explained in the synaptics documentation section 3.2, in this mode,
      the device sends a continuous stream of packets at the maximum rate
      to the host when the user's fingers are near or on the pad or
      pressing buttons, and continues streaming for 1 second afterwards.
      These packets are even sent when there is no new information to report,
      even when they are duplicates of the previous packet.
      
      For embedded systems this is a bit much - it results in a huge
      and uninterrupted stream of interrupts at high rate.
      
      This patch adds support for Relative mode, which can be selected as
      a new psmouse protocol. In this mode, the device does not send duplicate
      packets and acts like a standard PS/2 mouse. However, synaptics-specific
      functionality is still available, such as the ability to set the packet
      rate, and rather than disabling gestures and taps at the hardware level
      unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
      been added to allow control of this functionality.
      
      This solves a long standing OLPC issue: synaptics hardware enables
      tap to click by default (even in the default relative mode), but we
      have found this to be inappropriate for young children and first
      time computer users. Enabling the synaptics driver disables tap-to-click,
      but we have previously been unable to use this because it also enables
      Absolute mode, which is too "spammy" for our desires and actually
      overloads our EC with its continuous stream of packets. Now we can enable
      the synaptics driver, disabling tap to click while retaining the less
      noisy Relative mode.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      7968a5dd
  19. 11 10月, 2011 1 次提交
  20. 24 8月, 2011 7 次提交
    • D
      Input: synaptics - process finger (<=5) transitions · 6b4b49fe
      Daniel Kurtz 提交于
      Synaptics image sensor touchpads track up to 5 fingers, but only report 2.
      They use a special "TYPE=2" (AGM-CONTACT) packet type that reports
      the number of tracked fingers and which finger is reported in the SGM
      and AGM packets.
      
      With this new packet type, it is possible to tell userspace when 4 or 5
      fingers are touching.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Acked-by: NChase Douglas <chase.douglas@canonical.com>
      Acked-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      6b4b49fe
    • D
      Input: synaptics - process finger (<=3) transitions · 4dc772d2
      Daniel Kurtz 提交于
      Synaptics image sensor touchpads track 5 fingers, but only report 2.
      This patch attempts to deal with some idiosyncrasies of these touchpads:
      
       * When there are 3 or more fingers, only two are reported.
       * The touchpad tracks the 5 fingers in slot[0] through slot[4].
       * It always reports the lowest and highest valid slots in SGM and AGM
         packets, respectively.
       * The number of fingers is only reported in the SGM packet.  However,
         the number of fingers can change either before or after an AGM
         packet.
       * Thus, if an SGM reports a different number of fingers than the last
         SGM, it is impossible to tell whether the intervening AGM corresponds
         to the old number of fingers or the new number of fingers.
       * For example, when going from 2->3 fingers, it is not possible to tell
         whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
         3rd finger).
       * When fingers are added one at at time, from 1->2->3, it is possible to
         track which slots are contained in the SGM and AGM packets:
           1 finger:  SGM = slot[0], no AGM
           2 fingers: SGM = slot[0], AGM = slot[1]
           3 fingers: SGM = slot[0], AGM = slot[2]
       * It is also possible to track which slot is contained in the SGM when 1
         of 2 fingers is removed.  This is because the touchpad sends a special
         (0,0,0) AGM packet whenever all fingers are removed except slot[0]:
           Last AGM == (0,0,0): SGM contains slot[1]
           Else: SGM contains slot[0]
       * However, once there are 3 fingers, if exactly 1 finger is removed, it
         is impossible to tell which 2 slots are contained in SGM and AGM.
         The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
       * Similarly, if two fingers are simultaneously removed (3->1), then it
         is only possible to know if SGM still contains slot[0].
       * Since it is not possible to reliably track which slot is being
         reported, we invalidate the tracking_id every time the number of
         fingers changes until this ambiguity is resolved when:
           a) All fingers are removed.
           b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
           c) All fingers are removed except slot[0].  In this special case, the
              ambiguity is resolved since by the (0,0,0) AGM packet.
      
      Behavior of the driver:
      
      When 2 or more fingers are present on the touchpad, the kernel reports
      up to two MT-B slots containing the position data for two of the fingers
      reported by the touchpad.  If the identity of a finger cannot be tracked
      when the number-of-fingers changes, the corresponding MT-B slot will be
      invalidated (track_id set to -1), and a new track_id will be assigned in
      a subsequent input event report.
      
      The driver always reports the total number of fingers using one of the
      EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
      MT-B slots for two reasons:
       a) There are more than 2 fingers on the pad.
       b) During ambiguous number-of-fingers transitions, the correct track_id
          for one or both of the slots cannot be determined, so the slots are
          invalidated.
      
      Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
      this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
      events than its maximum EV_ABS/ABS_MT_SLOT.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Acked-by: NChase Douglas <chase.douglas@canonical.com>
      Acked-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      4dc772d2
    • D
      Input: synaptics - decode AGM packet types · a6ca40c1
      Daniel Kurtz 提交于
      A Synaptics image sensor tracks 5 fingers, but can only report 2.
      
      The algorithm for choosing which 2 fingers to report and in which packet:
        Touchpad maintains 5 slots, numbered 0 to 4
        Initially all slots are empty
        As new fingers are detected, assign them to the lowest available slots
        The touchpad always reports:
          SGM: lowest numbered non-empty slot
          AGM: highest numbered non-empty slot, if there is one
      
      In addition, these touchpads have a special AGM packet type which reports
      the number of fingers currently being tracked, and which finger is in
      each of the two slots.  Unfortunately, these "TYPE=2" packets are only used
      when more than 3 fingers are being tracked.  When less than 4 fingers
      are present, the 'w' value must be used to track how many fingers are
      present, and knowing which fingers are being reported is much more
      difficult, if not impossible.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Acked-by: NChase Douglas <chase.douglas@canonical.com>
      Acked-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      a6ca40c1
    • D
      Input: synaptics - add image sensor support · 3cdfee9e
      Daniel Kurtz 提交于
      Synaptics makes (at least) two kinds of touchpad sensors:
       * Older pads use a profile sensor that could only infer the location
         of individual fingers based on the projection of their profiles
         onto row and column sensors.
       * Newer pads use an image sensor that can track true finger position
         using a two-dimensional sensor grid.
      
      Both sensor types support an "Advanced Gesture Mode":
       When multiple fingers are detected, the touchpad sends alternating
       "Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
       packets.
       The AGM packets have w=2, and contain reduced resolution finger data
       The SGM packets have w={0,1} and contain full resolution finger data
      
      Profile sensors try to report the "upper" (larger y value) finger in
      the SGM packet, and the lower (smaller y value) in the AGM packet.
      However, due to the nature of the profile sensor, they easily get
      confused when fingers cross, and can start reporting the x-coordinate
      of one with the y-coordinate of the other.  Thus, for profile
      sensors, "semi-mt" was created, which reports a "bounding box"
      created by pairing min and max coordinates of the two pairs of
      reported fingers.
      
      Image sensors can report the actual coordinates of two of the fingers
      present.  This patch detects if the touchpad is an image sensor and
      reports finger data using the MT-B protocol.
      
      NOTE: This patch only adds partial support for 2-finger gestures.
            The proper interpretation of the slot contents when more than
            two fingers are present is left to later patches.  Also,
            handling of 'number of fingers' transitions is incomplete.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Acked-by: NChase Douglas <chase.douglas@canonical.com>
      Acked-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      3cdfee9e
    • D
    • D
      Input: synaptics - refactor agm packet parsing · 7afdb842
      Daniel Kurtz 提交于
      When a Synaptics touchpad is in "AGM" mode, and multiple fingers are
      detected, the touchpad sends alternating "Advanced Gesture Mode" (AGM) and
      "Simple Gesture Mode" (SGM) packets.
        The AGM packets have w=2, and contain reduced resolution finger data.
        The SGM packets have w={0,1} and contain full resolution finger data.
      
      Refactor the parsing of agm packets to its own function, and rename the
      synaptics_data.mt field to .agm to indicate that it contains the contents of
      the last agm packet.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Acked-by: NChase Douglas <chase.douglas@canonical.com>
      Acked-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      7afdb842
    • D
      Input: synaptics - refactor y inversion · 6de58dd6
      Daniel Kurtz 提交于
      Synaptics touchpads report increasing y from bottom to top.
      This is inverted from normal userspace "top of screen is 0" coordinates.
      Thus, the kernel driver reports inverted y coordinates to userspace.
      
      This patch refactors this inversion.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Acked-by: NChase Douglas <chase.douglas@canonical.com>
      Acked-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      6de58dd6
  21. 10 7月, 2011 1 次提交
  22. 07 7月, 2011 4 次提交
  23. 31 3月, 2011 1 次提交
  24. 29 1月, 2011 2 次提交
  25. 23 12月, 2010 2 次提交
  26. 22 12月, 2010 1 次提交