Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 09 3月, 2015 8 次提交
  3. 20 1月, 2015 1 次提交
  5. 17 11月, 2014 1 次提交
  7. 07 11月, 2014 1 次提交
  9. 12 10月, 2014 1 次提交
  11. 13 9月, 2014 1 次提交
  13. 10 9月, 2014 1 次提交
    • D
      Input: synaptics - add support for ForcePads · 5715fc76
      由 Dmitry Torokhov 提交于 
      ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of
physical buttons, instead they generate primary button click when user
presses somewhat hard on the surface of the touchpad. Unfortunately they
also report primary button click whenever there are 2 or more contacts
on the pad, messing up all multi-finger gestures (2-finger scrolling,
multi-finger tapping, etc). To cope with this behavior we introduce a
delay (currently 50 msecs) in reporting primary press in case more
contacts appear.

Cc: stable@vger.kernel.org
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      5715fc76
  15. 09 8月, 2014 1 次提交
    • H
      Input: synaptics - use firmware data for Cr-48 · e08d9afa
      由 Henrik Rydberg 提交于 
      The profile sensor clickpad in a Cr-48 Chromebook does a reasonable job
of tracking individual fingers. This tracking isn't perfect, but,
experiments show that it works better than just passing "semi-mt" data
to userspace, and making userspace try to deduce where the fingers are
given a bounding box.

This patch tries to report correct two-finger positions instead of the
{(min_x, min_y), (max_x, max_y)} for profile sensor clickpads on Cr-48
chromebooks. Note that this device's firmware always reports the higher
(smaller y) finger in the "sgm" packet, and the lower (larger y) finger
in the "agm" packet. Thus, when a new finger arrives on the pad, the
kernel driver uses input core's contact tracking facilities to match
contacts with slots.

Inspired by patch by Daniel Kurtz <djkurtz@chromium.org> and Chung-yih
Wang <cywang@chromium.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      e08d9afa
  17. 08 8月, 2014 1 次提交
  19. 15 7月, 2014 1 次提交
  21. 08 6月, 2014 1 次提交
  23. 27 5月, 2014 3 次提交
  25. 15 5月, 2014 1 次提交
  27. 24 4月, 2014 1 次提交
  29. 20 4月, 2014 2 次提交
  31. 29 3月, 2014 2 次提交
  33. 13 8月, 2013 1 次提交
  35. 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
  37. 16 2月, 2013 1 次提交
  39. 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
  41. 29 9月, 2012 1 次提交
  43. 20 9月, 2012 1 次提交
  45. 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
  47. 08 7月, 2012 1 次提交
  49. 11 5月, 2012 1 次提交
  51. 21 4月, 2012 1 次提交
  53. 12 12月, 2011 1 次提交
  55. 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
  57. 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