linux-stable.git/drivers/input/mouse/synaptics.c, branch linux-3.4.y

Input: synaptics - handle spurious release of trackstick buttons

2015-06-19T03:40:26+00:00

commit ebc80840b850db72f7ae84fbcf77630ae5409629 upstream.

The Fimware 8.1 has a bug in which the extra buttons are only sent when the
ExtBit is 1.  This should be fixed in a future FW update which should have
a bump of the minor version.

Signed-off-by: Benjamin Tissoires 
Acked-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Zefan Li

Input: synaptics - fix middle button on Lenovo 2015 products

2015-06-19T03:40:26+00:00

commit dc5465dc8a6d5cae8a0e1d8826bdcb2e4cb261ab upstream.

On the X1 Carbon 3rd gen (with a 2015 broadwell cpu), the physical middle
button of the trackstick (attached to the touchpad serio device, of course)
seems to get lost.

Actually, the touchpads reports 3 extra buttons, which falls in the switch
below to the '2' case. Let's handle the case of odd numbers also, so that
the middle button finds its way back.

Signed-off-by: Benjamin Tissoires 
Acked-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
[lizf: Backported to 3.4: open-code GENMASK]
Signed-off-by: Zefan Li

Input: synaptics - query min dimensions for fw v8.1

2015-06-19T03:40:26+00:00

commit ac097930f0730a9b777737de2b51e0fc49d2be7a upstream.

Query the min dimensions even if the check
SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 7 fails, but we know that the
firmware version 8.1 is safe.

With that we don't need quirks for post-2013 models anymore as they expose
correct min and max dimensions.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541

Signed-off-by: Daniel Martin 
  re-order the tests to check SYN_CAP_MIN_DIMENSIONS even on FW 8.1
Signed-off-by: Benjamin Tissoires 
Acked-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Zefan Li

Input: synaptics - gate forcepad support by DMI check

2015-02-02T09:04:49+00:00

commit aa972409951e0675e07918620427517cad5090e0 upstream.

Unfortunately, ForcePad capability is not actually exported over PS/2, so
we have to resort to DMI checks.

Reported-by: Nicole Faerber 
Signed-off-by: Dmitry Torokhov 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

Input: synaptics - add support for ForcePads

2014-12-01T10:02:28+00:00

commit 5715fc764f7753d464dbe094b5ef9cffa6e479a4 upstream.

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.

Reviewed-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Zefan Li

Input: synaptics - adjust threshold for treating position values as negative

2014-06-07T23:02:06+00:00

commit 824efd37415961d38821ecbd9694e213fb2e8b32 upstream.

Commit c039450 (Input: synaptics - handle out of bounds values from the
hardware) caused any hardware reported values over 7167 to be treated as
a wrapped-around negative value. It turns out that some firmware uses
the value 8176 to indicate a finger near the edge of the touchpad whose
actual position cannot be determined. This value now gets treated as
negative, which can cause pointer jumps and broken edge scrolling on
these machines.

I only know of one touchpad which reports negative values, and this
hardware never reports any value lower than -8 (i.e. 8184). Moving the
threshold for treating a value as negative up to 8176 should work fine
then for any hardware we currently know about, and since we're dealing
with unspecified behavior it's probably the best we can do. The special
8176 value is also likely to result in sudden jumps in position, so
let's also clamp this to the maximum specified value for the axis.

BugLink: http://bugs.launchpad.net/bugs/1046512
https://bugzilla.kernel.org/show_bug.cgi?id=46371

Signed-off-by: Seth Forshee 
Reviewed-by: Daniel Kurtz 
Tested-by: Alan Swanson 
Tested-by: Arteom 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Ben Hutchings 
Cc: Qiang Huang 
Signed-off-by: Greg Kroah-Hartman

Input: synaptics - add manual min/max quirk for ThinkPad X240

2014-04-03T18:58:46+00:00

commit 8a0435d958fb36d93b8df610124a0e91e5675c82 upstream.

This extends Benjamin Tissoires manual min/max quirk table with support for
the ThinkPad X240.

Signed-off-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: synaptics - add manual min/max quirk

2014-04-03T18:58:46+00:00

commit 421e08c41fda1f0c2ff6af81a67b491389b653a5 upstream.

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 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: synaptics - handle out of bounds values from the hardware

2014-02-20T18:45:33+00:00

commit c0394506e69b37c47d391c2a7bbea3ea236d8ec8 upstream.

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
Signed-off-by: Seth Forshee 
Reviewed-by: Daniel Kurtz 
Signed-off-by: Dmitry Torokhov 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
Cc: Li Zefan 
Signed-off-by: Greg Kroah-Hartman

Input: synaptics - fix regression with "image sensor" trackpads

2012-04-21T05:47:28+00:00

commit 7968a5dd492ccc38345013e534ad4c8d6eb60ed1
Input: synaptics - add support for Relative mode

Accidentally broke support for advanced gestures (multitouch)
on some trackpads such as the one in my ThinkPad X220 by
incorretly changing the condition for enabling them. This
restores it.

Signed-off-by: Benjamin Herrenschmidt 
CC: stable@kernel.org [3.3]
Signed-off-by: Dmitry Torokhov