linux-toradex.git/drivers/input/mouse, branch v3.4.108

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: alps - allow up to 2 invalid packets without resetting device

2015-02-02T09:05:19+00:00

commit 9d720b34c0a432639252f63012e18b0507f5b432 upstream.

On some Dell Latitude laptops ALPS device or Dell EC send one invalid byte
in 6 bytes ALPS packet. In this case psmouse driver enter out of sync
state. It looks like that all other bytes in packets are valid and also
device working properly. So there is no need to do full device reset, just
need to wait for byte which match condition for first byte (start of
packet). Because ALPS packets are bigger (6 or 8 bytes) default limit is
small.

This patch increase number of invalid bytes to size of 2 ALPS packets which
psmouse driver can drop before do full reset.

Resetting ALPS devices take some time and when doing reset on some Dell
laptops touchpad, trackstick and also keyboard do not respond. So it is
better to do it only if really necessary.

Signed-off-by: Pali Rohár 
Tested-by: Pali Rohár 
Reviewed-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Zefan Li

Input: alps - ignore potential bare packets when device is out of sync

2015-02-02T09:05:18+00:00

commit 4ab8f7f320f91f279c3f06a9795cfea5c972888a upstream.

5th and 6th byte of ALPS trackstick V3 protocol match condition for first
byte of PS/2 3 bytes packet. When driver enters out of sync state and ALPS
trackstick is sending data then driver match 5th, 6th and next 1st bytes as
PS/2.

It basically means if user is using trackstick when driver is in out of
sync state driver will never resync. Processing these bytes as 3 bytes PS/2
data cause total mess (random cursor movements, random clicks) and make
trackstick unusable until psmouse driver decide to do full device reset.

Lot of users reported problems with ALPS devices on Dell Latitude E6440,
E6540 and E7440 laptops. ALPS device or Dell EC for unknown reason send
some invalid ALPS PS/2 bytes which cause driver out of sync. It looks like
that i8042 and psmouse/alps driver always receive group of 6 bytes packets
so there are no missing bytes and no bytes were inserted between valid
ones.

This patch does not fix root of problem with ALPS devices found in Dell
Latitude laptops but it does not allow to process some (invalid)
subsequence of 6 bytes ALPS packets as 3 bytes PS/2 when driver is out of
sync.

So with this patch trackstick input device does not report bogus data when
also driver is out of sync, so trackstick should be usable on those
machines.

Signed-off-by: Pali Rohár 
Tested-by: Pali Rohár 
Reviewed-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: elantech - fix detection of touchpad on ASUS s301l

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

commit 271329b3c798b2102120f5df829071c211ef00ed upstream.

Adjust Elantech signature validation to account fo rnewer models of
touchpads.

Reported-and-tested-by: Màrius Monton 
Signed-off-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Zefan Li

Input: elantech - deal with clickpads reporting right button events

2014-07-07T01:49:19+00:00

commit cd9e83e2754465856097f31c7ab933ce74c473f8 upstream.

At least the Dell Vostro 5470 elantech *clickpad* reports right button
clicks when clicked in the right bottom area:

https://bugzilla.redhat.com/show_bug.cgi?id=1103528

This is different from how (elantech) clickpads normally operate, normally
no matter where the user clicks on the pad the pad always reports a left
button event, since there is only 1 hardware button beneath the path.

It looks like Dell has put 2 buttons under the pad, one under each bottom
corner, causing this.

Since this however still clearly is a real clickpad hardware-wise, we still
want to report it as such to userspace, so that things like finger movement
in the bottom area can be properly ignored as it should be on clickpads.

So deal with this weirdness by simply mapping a right click to a left click
on elantech clickpads. As an added advantage this is something which we can
simply do on all elantech clickpads, so no need to add special quirks for
this weird model.

Reported-and-tested-by: Elder Marco 
Signed-off-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

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