Skip to content

C
clone-Linux

gsplhtlxg / clone-Linux

通知 2
Star 0
Fork 1
C
clone-Linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 07 3月, 2015 1 次提交
  3. 16 2月, 2015 1 次提交
  5. 04 2月, 2015 1 次提交
    • B
      Input: synaptics - use dmax in input_mt_assign_slots · 6ab17a84
      由 Benjamin Tissoires 提交于 
      When tapping a clickpad with two fingers, there is a chance that the sensor
sees first only one finger, and at the next scan only the second one.  In
this case, the sensors says that there has been only one finger on the
clickpad, which moved really fast between two scans.

We can try to counter this by adding a limit to what an actual finger can
move between 2 scans.  A distance of 1cm between two scans for one finger
seems reasonable.  However, this is not really accurate because the
resolution in X and in Y differs. But heh, that's how the in-kernel
tracking works right now, and its job is quite good, even with this
approximation.

This parameter solves most of the jumps observed, not all of them however.
But this is a hardware defect, and we might not be able to get something
better without much heavier computations.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76722Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      6ab17a84
  7. 02 2月, 2015 1 次提交
  9. 20 1月, 2015 1 次提交
  11. 30 12月, 2014 2 次提交
    • B
      Input: synaptics - remove duplicated code · aa104b1a
      由 Benjamin Tissoires 提交于 
      synaptics_profile_sensor_process() and synaptics_report_mt_data() now
share the exact same code. Remove one implementation and rely on the
other where it was used.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      aa104b1a
    • B
      Input: synaptics - use in-kernel tracking for reporting mt data · e9e8520f
      由 Benjamin Tissoires 提交于 
      The current code tries to consider all states and transitions to properly
detect which finger is attached to which slot. The code is quite huge
and difficult to read.

If the sensor manages to group the touch points but is not reliable in
giving tracking ids, we can simply use the kernel tracking method. Note
that it is already used by Cr-48 Chromebooks.

Incidentaly, this fixes a bug reported by Peter Hutterer:
"""
on the Lenovo T440, run:
evemu-record /dev/input/event4 | grep BTN_

then put one, two, three, two fingers down
when you go from 3 to 2 fingers the driver sends a spurious BTN_TOUCH 0
event:

E: 0.000000 0001 014a 0001      # EV_KEY / BTN_TOUCH            1
E: 0.000000 0001 0145 0001      # EV_KEY / BTN_TOOL_FINGER      1
E: 0.770008 0001 0145 0000      # EV_KEY / BTN_TOOL_FINGER      0
E: 0.770008 0001 014d 0001      # EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 1.924716 0001 014d 0000      # EV_KEY / BTN_TOOL_DOUBLETAP   0
E: 1.924716 0001 014e 0001      # EV_KEY / BTN_TOOL_TRIPLETAP   1

.. changing from 3 to 2 fingers now

E: 3.152641 0001 014a 0000      # EV_KEY / BTN_TOUCH            0
E: 3.152641 0001 014d 0001      # EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 3.152641 0001 014e 0000      # EV_KEY / BTN_TOOL_TRIPLETAP   0
E: 3.176948 0001 014a 0001      # EV_KEY / BTN_TOUCH            1

quick look in the kernel shows it's caused by hw.z going to 0 for a packet,
so probably a firmware bug. either way, it makes it hard to track BTN_TOUCH
as signal that at least one finger is down.
"""

The in-kernel tracking is enough to remove this spurious BTN_TOUCH 0.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      e9e8520f
  13. 17 11月, 2014 1 次提交
  15. 07 11月, 2014 1 次提交
  17. 12 10月, 2014 1 次提交
  19. 13 9月, 2014 1 次提交
  21. 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
  23. 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
  25. 08 8月, 2014 1 次提交
  27. 15 7月, 2014 1 次提交
  29. 08 6月, 2014 1 次提交
  31. 27 5月, 2014 3 次提交
  33. 15 5月, 2014 1 次提交
  35. 24 4月, 2014 1 次提交
  37. 20 4月, 2014 2 次提交
  39. 29 3月, 2014 2 次提交
  41. 13 8月, 2013 1 次提交
  43. 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
  45. 16 2月, 2013 1 次提交
  47. 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
  49. 29 9月, 2012 1 次提交
  51. 20 9月, 2012 1 次提交
  53. 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
  55. 08 7月, 2012 1 次提交
  57. 11 5月, 2012 1 次提交
  59. 21 4月, 2012 1 次提交
  61. 12 12月, 2011 1 次提交
  63. 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
  65. 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
  67. 11 10月, 2011 1 次提交
  69. 24 8月, 2011 1 次提交