kernel/linux.git/drivers/input/mouse/elantech.h, branch v4.12.9

Input: elantech - add special check for fw_version 0x470f01 touchpad

2015-08-07T21:54:15+00:00

It is no need to check the packet[0] for sanity check when doing elantech_packet_check_v4() function for fw_version = 0x470f01 touchpad. Signed-off by: Duson Lin Reviewed-by: Ulrik De Bie Signed-off-by: Dmitry Torokhov

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

2015-04-06T22:39:07+00:00

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 Cc: stable@vger.kernel.org Reported-and-tested-by: George Moutsopoulos Signed-off-by: Ulrik De Bie Signed-off-by: Dmitry Torokhov

Input: elantech - add support for trackpoint found on some v3 models

2014-08-26T22:17:41+00:00

Some elantech v3 touchpad equipped laptops also have a trackpoint, before this commit, these give sync errors. With this patch, the trackpoint is provided as another input device: 'Elantech PS/2 TrackPoint' The patch will also output messages that do not follow the expected pattern. In the mean time I've seen 2 unknown packets occasionally: 0x04 , 0x00 , 0x00 , 0x00 , 0x00 , 0x00 0x00 , 0x00 , 0x00 , 0x02 , 0x00 , 0x00 I don't know what those are for, but they can be safely ignored. Currently all packets that are not known to v3 touchpad and where packet[3] (the fourth byte) lowest nibble is 6 are now recognized as PACKET_TRACKPOINT and processed by the new elantech_report_trackpoint. This has been verified to work on a laptop Lenovo L530 where the touchpad/trackpoint combined identify themselves as: psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x350f02) psmouse serio1: elantech: Synaptics capabilities query result 0xb9, 0x15, 0x0c. Reviewed-by: David Herrmann Reviewed-by: Hans de Goede Signed-off-by: Ulrik De Bie Signed-off-by: Dmitry Torokhov

Input: elantech - fix touchpad initialization on Gigabyte U2442

2014-05-05T19:34:22+00:00

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 Cc: stable@vger.kernel.org Reported-by: Philipp Wolfer Tested-by: Philipp Wolfer Signed-off-by: Hans de Goede 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

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

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