The LEN2006 Synaptics touchpad (as found in Thinkpad E540) returns wrong
min max values.
touchpad-edge-detector output:
> Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event6
> Move one finger around the touchpad to detect the actual edges
> Kernel says: x [1472..5674], y [1408..4684]
> Touchpad sends: x [1264..5675], y [1171..4688]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88211
Cc: stable@vger.kernel.org
Signed-off-by: Binyamin Sagal <bensagal@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The matches_pnp_id function from the synaptics driver is useful for other
drivers too. Make it a generic psmouse helper function.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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: Henrik Rydberg <rydberg@euromail.se>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Semi-MT devices are pointers too, so let's tell that to
input_mt_init_slots(), as well as let it set up the devices as semi-MT,
instead of us doing it manually.
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
commit 421e08c41f fixed the reported min/max for the X and Y axis,
but unfortunately, it broke the resolution of those same axis.
On the t540p, the resolution is the same regarding X and Y. It is not
a problem for xf86-input-synaptics because this driver is only interested
in the ratio between X and Y.
Unfortunately, xf86-input-cmt uses directly the resolution, and having a
null resolution leads to some divide by 0 errors, which are translated by
-infinity in the resulting coordinates.
Reported-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Most of the affected models share pnp-ids for the touchpad. So switching
to pnp-ids give us 2 advantages:
1) It shrinks the quirk list
2) It will lower the new quirk addition frequency, ie the recently added W540
quirk would not have been necessary since it uses the same LEN0034 pnp ids
as other models already added before it
As an added bonus it actually puts the quirk on the actual psmouse, rather
then on the machine, which is technically more correct.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The T540p has a touchpad with pnp-id LEN0034, all the models with this
pnp-id have the same min/max values, except the T540p where the values are
slightly off. Fix them to be identical.
This is a preparation patch for simplifying the quirk table.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We expect that all the Haswell series will need such quirks, sigh.
The T431s seems to be T430 hardware in a T440s case, using the T440s touchpad,
with the same min/max issue.
The X1 Carbon 3rd generation name says 2nd while it is a 3rd generation.
The X1 and T431s share a PnPID with the T540p, but the reported ranges are
closer to those of the T440s.
HdG: Squashed 5 quirk patches into one. T431s + L440 + L540 are written by me,
S1 Yoga and X1 are written by Benjamin Tissoires.
Hdg: Standardized S1 Yoga and X1 values, Yoga uses the same touchpad as the
X240, X1 uses the same touchpad as the T440.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD
property for for touchpads with top button areas.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad.
However, these new Synaptics devices report bad axis ranges.
Under Windows, it is not a problem because the Windows driver uses RMI4
over SMBus to talk to the device. Under Linux, we are using the PS/2
fallback interface and it occurs the reported ranges are wrong.
Of course, it would be too easy to have only one range for the whole
series, each touchpad seems to be calibrated in a different way.
We can not use SMBus to get the actual range because I suspect the firmware
will switch into the SMBus mode and stop talking through PS/2 (this is the
case for hybrid HID over I2C / PS/2 Synaptics touchpads).
So as a temporary solution (until RMI4 land into upstream), start a new
list of quirks with the min/max manually set.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
CC: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
__initconst should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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: Daniel Manrique <daniel.manrique@canonical.com>
Signed-off-by: James M Leddy <james.leddy@canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To properly setup event parameters for emulated events, pass
the appropriate flag to the slot initialization function. Also,
all MT-related events should be setup before initialization.
Incidentally, this solves the issue of doubly filtered pointer
events.
Reported-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Peter Hutterer
Ben Sagal
Takashi Iwai
Dmitry Torokhov
Hans de Goede
Henrik Rydberg
Dmitry Torokhov
Benjamin Tissoires
Sachin Kamat
Eric Miao
Daniel Kurtz