linux-toradex.git/drivers/input/mouse/elantech.c, branch v3.2.64

Input: elantech - fix detection of touchpad on ASUS s301l

2014-11-05T20:27:41+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: Ben Hutchings

Input: elantech - don't set bit 1 of reg_10 when the no_hw_res quirk is set

2014-07-11T12:33:48+00:00

commit fb4f8f568a9def02240ef9bf7aabd246dc63a081 upstream.

The touchpad on the GIGABYTE U2442 not only stops communicating when we try
to set bit 3 (enable real hardware resolution) of reg_10, but on some BIOS
versions also when we set bit 1 (enable two finger mode auto correct).

I've asked the original reporter of:
https://bugzilla.kernel.org/show_bug.cgi?id=61151

To check that not setting bit 1 does not lead to any adverse effects on his
model / BIOS revision, and it does not, so this commit fixes the touchpad
not working on these versions by simply never setting bit 1 for laptop
models with the no_hw_res quirk.

Reported-and-tested-by: James Lademann 
Tested-by: Philipp Wolfer 
Signed-off-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Ben Hutchings

Input: elantech - deal with clickpads reporting right button events

2014-07-11T12:33:48+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: Ben Hutchings

Input: elantech - fix touchpad initialization on Gigabyte U2442

2014-06-09T12:29:08+00:00

commit 36189cc3cd57ab0f1cd75241f93fe01de928ac06 upstream.

The hw_version 3 Elantech touchpad on the Gigabyte U2442 does not accept
0x0b as initialization value for r10, this stand-alone version of the
driver: http://planet76.com/drivers/elantech/psmouse-elantech-v6.tar.bz2

Uses 0x03 which does work, so this means not setting bit 3 of r10 which
sets: "Enable Real H/W Resolution In Absolute mode"

Which will result in half the x and y resolution we get with that bit set,
so simply not setting it everywhere is not a solution. We've been unable to
find a way to identify touchpads where setting the bit will fail, so this
patch uses a dmi based blacklist for this.

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

Reported-by: Philipp Wolfer 
Tested-by: Philipp Wolfer 
Signed-off-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

Input: elantech - adjust hw_version detection logic

2011-11-10T05:19:47+00:00

This patch fixes some v3 hardware (fw_version: 0x150500) wrongly detected
as v2 hardware.

Reported-by: Marc Dietrich 
Signed-off-by: JJ Ding 
Tested-By: Marc Dietrich 
Acked-by: Éric Piel 
Signed-off-by: Dmitry Torokhov

Input: psmouse - switch to using dev_*() for messages

2011-10-11T01:28:16+00:00

This will ensure our reporting is consistent with the rest of the system
and we do not refer to obsolete source file names.

Reviewed-by: Wanlong Gao 
Reviewed-by: JJ Ding 
Reviewed-by: Daniel Kurtz 
Signed-off-by: Dmitry Torokhov

Input: elantech - remove module parameter force_elantech

2011-09-21T05:46:28+00:00

This essentially reverts commit f81bc788ff91d4efd4baf88b2c29713838caa8e5.

With recent work on elantech driver, I believe we now have complete support
for all elantech touchpads. So remove this hack.

Signed-off-by: JJ Ding 
Reviewed-by: Éric Piel 
Signed-off-by: Dmitry Torokhov

Input: elantech - better support all those v2 variants

2011-09-21T05:46:27+00:00

V2 hardware has many variants. This patch adddresses two issues:

 - some model also has debounce packets, but with a different signature
   than v3. Now we just check debounce for all v2 hardware.

 - due to different scanning methods the hardware uses, x and y ranges have
   to be calculated differently. And for some specific versions, we can just
   see them as custom-made, so set {x, y} the same values as Windows driver
   does.

Signed-off-by: JJ Ding 
Tested-by: Richard Schütz 
Reviewed-by: Éric Piel 
Signed-off-by: Dmitry Torokhov

Input: elantech - add v4 hardware support

2011-09-09T17:35:02+00:00

v4 hardware is a true multitouch capable touchpad (up to 5 fingers).
The packet format is quite complex, please see protocol document for
reference.

Signed-off-by: JJ Ding 
Signed-off-by: Dmitry Torokhov

Input: elantech - add v3 hardware support

2011-09-09T17:34:58+00:00

v3 hardware's packet format is almost identical to v2 (one/three finger touch),
except when sensing two finger touch, the hardware sends 12 bytes of data.

Signed-off-by: JJ Ding 
Acked-by: Daniel Kurtz 
Acked-by: Éric Piel 
Signed-off-by: Dmitry Torokhov