linux.git/drivers/input/mouse, branch v3.18.4

Input: elantech - support new ICs types for version 4

2015-01-27T16:29:43+00:00

commit 810aa0918b2b032684c8cad13f73d6ba37ad11c0 upstream.

This change allows the driver to recognize newer Elantech touchpads.

Signed-off-by: Yi ju Hong 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: alps - v7: fix finger counting for > 2 fingers on clickpads

2015-01-16T14:59:55+00:00

commit d27eb7931c98a1ebfc9b2fcc48939846bcbfc804 upstream.

Protocol v7 uses the middle / right button bits on clickpads to communicate
"location" information of a 3th touch (and possible 4th) touch on
clickpads.

Specifically when 3 touches are down, if one of the 3 touches is in the
left / right button area, this will get reported in the middle / right
button bits and the touchpad will still send a TWO type packet rather then
a MULTI type packet, so when this happens we must add the finger reported
in the button area to the finger count.

Likewise we must also add fingers reported this way to the finger count
when we get MULTI packets.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338
Signed-off-by: Hans de Goede 
Tested-by: Benjamin Tissoires 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: alps - v7: sometimes a single touch is reported in mt[1]

2015-01-16T14:59:55+00:00

commit 7091c443dda8c6c6d8e70e33452252f9ad3e7814 upstream.

The v7 proto differentiates between a primary touch (with high precision)
and a secondary touch (with lower precision). Normally when 2 fingers are
down and one is lifted the still present touch becomes the primary touch,
but some traces have shown that this does not happen always.

This commit deals with this by making alps_get_mt_count() not stop at the
first empty mt slot, and if a touch is present in mt[1] and not mt[0]
moving the data to mt[0] (for input_mt_assign_slots).

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338
Signed-off-by: Hans de Goede 
Tested-by: Benjamin Tissoires 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: alps - v7: ignore new packets

2015-01-16T14:59:55+00:00

commit 8b23811535d2e1dd6abbe4ce6ea1edfd50ce72de upstream.

NEW packets are send to indicate a discontinuity in the finger coordinate
reporting. Specifically a finger may have moved from slot 0 to 1 or vice
versa.  INPUT_MT_TRACK takes care of this for us.

NEW packets have 3 problems:
1) They do not contain middle / right button info (on non clickpads)
   this can be worked around by preserving the old button state
2) They do not contain an accurate fingercount, and they are
   typically send when the number of fingers changes. We cannot use
   the old finger count as that may mismatch with the amount of
   touch coordinates we've available in the NEW packet
3) Their x data for the second touch is inaccurate leading to
   a possible jump of the x coordinate by 16 units when the first
   non NEW packet comes in

Since problems 2 & 3 cannot be worked around, just ignore them.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338
Signed-off-by: Hans de Goede 
Tested-by: Benjamin Tissoires 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: elantech - trust firmware about trackpoint presence

2014-11-25T08:42:13+00:00

Only try to parse data as coming from trackpoint if firmware told us that
trackpoint is present.

Fixes commit caeb0d37fa3e387eb0dd22e5d497523c002033d1

Reported-and-tested-by: Marcus Overhagen 
Reported-and-tested-by: Anders Kaseorg 
Signed-off-by: Dmitry Torokhov

Input: synaptics - adjust min/max on Thinkpad E540

2014-11-17T02:22:38+00:00

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

Input: elantech - provide a sysfs knob for crc_enabled

2014-11-14T01:50:23+00:00

The detection of crc_enabled is known to fail for Fujitsu H730. A DMI
blacklist is added for that, but it can be expected that other laptops will
pop up with this.

Here a sysfs knob is provided to alter the behaviour of crc_enabled.
Writing 0 or 1 to it sets the variable to 0 or 1. Reading it will show the
crc_enabled variable (0 or 1).

Reported-by: Stefan Valouch 
Signed-off-by: Ulrik De Bie 
Signed-off-by: Dmitry Torokhov

Input: elantech - report the middle button of the touchpad

2014-11-14T01:50:22+00:00

In the past, no elantech was known with 3 touchpad mouse buttons.
Fujitsu H730 is the first known elantech with a middle button. This commit
enables this middle button. For backwards compatibility, the Fujitsu is
detected via DMI, and only for this one 3 buttons will be announced.

Reported-by: Stefan Valouch 
Signed-off-by: Ulrik De Bie 
Signed-off-by: Dmitry Torokhov

Input: alps - ignore bad data on Dell Latitudes E6440 and E7440

2014-11-14T01:42:57+00:00

Sometimes on Dell Latitude laptops psmouse/alps driver receive invalid ALPS
protocol V3 packets with bit7 set in last byte. More often it can be
reproduced on Dell Latitude E6440 or E7440 with closed lid and pushing
cover above touchpad.

If bit7 in last packet byte is set then it is not valid ALPS packet. I was
told that ALPS devices never send these packets. It is not know yet who
send those packets, it could be Dell EC, bug in BIOS and also bug in
touchpad firmware...

With this patch alps driver does not process those invalid packets, but
instead of reporting PSMOUSE_BAD_DATA, getting into out of sync state,
getting back in sync with the next byte and spam dmesg we return
PSMOUSE_FULL_PACKET. If driver is truly out of sync we'll fail the checks
on the next byte and report PSMOUSE_BAD_DATA then.

Signed-off-by: Pali Rohár 
Tested-by: Pali Rohár 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov

Input: alps - allow up to 2 invalid packets without resetting device

2014-11-10T06:58:38+00:00

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 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov