kernel/linux.git/drivers/input/mouse/elantech.c, branch v3.14.47

Input: elantech - fix detection of touchpads where the revision matches a known rate

2015-06-23T00:01:20+00:00

commit 5f0ee9d17aae628b22be86966471db65be21f262 upstream. Make the check to skip the rate check more lax, so that it applies to all hw_version 4 models. This fixes the touchpad not being detected properly on Asus PU551LA laptops. Reported-and-tested-by: David Zafra Gómez Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: elantech - fix semi-mt protocol for v3 HW

2015-06-06T15:19:39+00:00

commit 3c0213d17a09601e0c6c0ae0e27caf70d988290f upstream. When the v3 hardware sees more than one finger, it uses the semi-mt protocol to report the touches. However, it currently works when num_fingers is 0, 1 or 2, but when it is 3 and above, it sends only 1 finger as if num_fingers was 1. This confuses userspace which knows how to deal with extra fingers when all the slots are used, but not when some are missing. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90101 Signed-off-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: elantech - fix absolute mode setting on some ASUS laptops

2015-05-06T19:59:14+00:00

commit bd884149aca61de269fd9bad83fe2a4232ffab21 upstream. On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done. In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that performs the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware). Also the ASUS TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c Reported-and-tested-by: George Moutsopoulos Signed-off-by: Ulrik De Bie Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: elantech - fix detection of touchpad on ASUS s301l

2014-10-05T21:52:19+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: Greg Kroah-Hartman

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

2014-07-07T01:57:26+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: Greg Kroah-Hartman

Input: elantech - deal with clickpads reporting right button events

2014-07-07T01:57:26+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: elantech - fix touchpad initialization on Gigabyte U2442

2014-06-07T17:28:20+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 Signed-off-by: Greg Kroah-Hartman

Input: elantech - improve clickpad detection

2013-12-18T16:47:29+00:00

The current assumption in the elantech driver that hw version 3 touchpads are never clickpads and hw version 4 touchpads are always clickpads is wrong. There are several bug reports for this, ie: https://bugzilla.redhat.com/show_bug.cgi?id=1030802 http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux I've spend a couple of hours wading through various bugzillas, launchpads and forum posts to create a list of fw-versions and capabilities for different laptop models to find a good method to differentiate between clickpads and versions with separate hardware buttons. Which shows that a device being a clickpad is reliable indicated by bit 12 being set in the fw_version. I've included the gathered list inside the driver, so that we've this info at hand if we need to revisit this later. Signed-off-by: Hans de Goede Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov

Input: elantech - add support for newer (August 2013) devices

2013-12-05T20:49:49+00:00

Added detection for newer Elantech touchpads, so that kernel doesn't fall-back to default PS/2 driver. Supports touchpads released after ~August 2013. Fixes bug: https://lists.launchpad.net/kernel-packages/msg18481.html Tested on an Acer Aspire S7-392-6302. Signed-off by: Matt Walker Signed-off-by: Dmitry Torokhov

Input: elantech - fix packet check for v3 and v4 hardware

2013-08-25T00:52:35+00:00

The signatures of v3 and v4 packets change depending on the value of a hardware flag called 'crc_enabled'. The packet type detection must change accordingly. This patch also restores a consistency check for v4 packets inadvertently removed by commit: 9eebed7de660c0b5ab129a9de4f89d20b60de68c Input: elantech - fix for newer hardware versions (v7) A note about the naming convention: v3 hardware is associated with IC body v5 while v4 hardware is associated with IC body v6 and v7. The above commit refers to IC body v7, not to v7 hardware. Tested on Samsung NP730U3E (fw = 0x675f05, ICv7, crc_enabled = 1) Tested-by: Giovanni Frigione Signed-off-by: Matteo Delfino Signed-off-by: Dmitry Torokhov