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

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

2014-07-07T01:54:13+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:54:13+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-07T20:25:36+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

2014-03-31T16:58:14+00:00

commit c15bdfd5b9831e4cab8cfc118243956e267dd30e upstream. 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 Cc: Josh Boyer Signed-off-by: Greg Kroah-Hartman

Input: MT - Add flags to input_mt_init_slots()

2012-09-19T17:50:18+00:00

Preparing to move more repeated code into the mt core, add a flags argument to the input_mt_slots_init() function. Reviewed-and-tested-by: Benjamin Tissoires Tested-by: Ping Cheng Acked-by: Dmitry Torokhov Signed-off-by: Henrik Rydberg

Input: elantech - v4 is a clickpad, with only one button

2012-04-10T07:40:35+00:00

Add pointer and buttonpad properties for v4 hardware. Also, Jachiet reported that on Asus UX31, right button has no effect. It turns out v4 has only one button, the right-button effect is implemented with software when Windows driver is installed, or in firmware when touchpad is in relative mode. So remove BTN_RIGHT while at it. Reported-by: Jachiet Louis Signed-off-by: JJ Ding Reviewed-by: Chase Douglas Signed-off-by: Dmitry Torokhov

Input: elantech - reset touchpad before configuring it

2012-04-10T07:40:31+00:00

Acer VH40 has a Fn key toggling the touchpad on and off, but it's implemented in system firmware, and the EC chip has to receive reset command to activate this function. Also when this machine wakes up after resume, psmouse_reset is necessary to bring the touchpad back on. Signed-off-by: JJ Ding Reviewed-by: Chase Douglas Signed-off-by: Dmitry Torokhov

Merge commit 'v3.2-rc3' into next

2011-11-29T09:51:07+00:00

Input: elantech - add resolution query support for v4 hardware

2011-11-21T06:28:34+00:00

It turns out that v4's firmware provides a command so we can query the resolution. Let's use it. Signed-off-by: JJ Ding Reviewed-by: Daniel Kurtz Signed-off-by: Dmitry Torokhov

Input: elantech - add support for elantech fast command

2011-11-21T06:28:30+00:00

Starting with v3 hardware, the firmware supports this shorter elantech_send_cmd. Teach the driver to use it. Signed-off-by: JJ Ding Reviewed-by: Daniel Kurtz Signed-off-by: Dmitry Torokhov