summaryrefslogtreecommitdiffstats
path: root/drivers/input/mouse/elantech.c
Commit message (Collapse)AuthorAgeFilesLines
* Input: elantech - add new icbody type洪一竹2015-06-041-0/+1
| | | | | | | | This adds new icbody type to the list recognized by Elantech PS/2 driver. Cc: stable@vger.kernel.org Signed-off-by: Sam Hung <sam.hung@emc.com.tw> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - fix detection of touchpads where the revision matches a ↵Hans de Goede2015-06-021-3/+4
| | | | | | | | | | | | | | | known rate 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. Cc: stable@vger.kernel.org Reported-and-tested-by: David Zafra Gómez <dezeta@klo.es> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - fix semi-mt protocol for v3 HWBenjamin Tissoires2015-05-131-1/+1
| | | | | | | | | | | | | | | | 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 Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - fix absolute mode setting on some ASUS laptopsUlrik De Bie2015-04-061-0/+22
| | | | | | | | | | | | | | | | | | | 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 <gmoutso@yahoo.co.uk> Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - add more Fujtisu notebooks to force crc_enabledRainer Koenig2015-02-011-0/+16
| | | | | | | | | Add two more Fujitsu LIFEBOOK models that also ship with the Elantech touchpad and don't work with crc_disabled to the quirk list. Signed-off-by: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com> Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - support new ICs types for version 4Sam hung2015-01-081-0/+2
| | | | | | | | This change allows the driver to recognize newer Elantech touchpads. Cc: stable@vger.kernel.org Signed-off-by: Yi ju Hong <sam.hung@emc.com.tw> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - trust firmware about trackpoint presenceDmitry Torokhov2014-11-251-9/+1
| | | | | | | | | | | 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 <marcus.overhagen@gmail.com> Reported-and-tested-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - provide a sysfs knob for crc_enabledUlrik De Bie2014-11-131-0/+2
| | | | | | | | | | | | | | 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 <stefan@valouch.com> Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - report the middle button of the touchpadUlrik De Bie2014-11-131-0/+19
| | | | | | | | | | | 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 <stefan@valouch.com> Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - fix crc_enabled for Fujitsu H730Ulrik De Bie2014-11-081-1/+18
| | | | | | | | | | | | | | The Fujitsu H730 does not work with crc_enabled = 0, even though the crc_enabled bit in the firmware version indicated it would. When switching this value to crc_enabled to 1, the touchpad works. This patch uses DMI to detect H730. Reported-by: Stefan Valouch <stefan@valouch.com> Tested-by: Stefan Valouch <stefan@valouch.com> Tested-by: Alfredo Gemma <alfredo.gemma@gmail.com> Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - use elantech_report_trackpoint for hardware v4 tooUlrik De Bie2014-11-081-2/+14
| | | | | | | | | | | | The Fujitsu H730 has hardware v4 with a trackpoint. This enables the elantech_report_trackpoint for v4. Reported-by: Stefan Valouch <stefan@valouch.com> Tested-by: Stefan Valouch <stefan@valouch.com> Tested-by: Alfredo Gemma <alfredo.gemma@gmail.com> Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: add missing POINTER / DIRECT properties to a bunch of driversHans de Goede2014-09-081-0/+1
| | | | | | | | I've not done a full audit of all mouse drivers, I noticed these ones were missing the POINTER property while working on the POINTING_STICK property. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: add INPUT_PROP_POINTING_STICK propertyHans de Goede2014-09-081-0/+3
| | | | | | | | | | | | | | | | | | | It is useful for userspace to know that there not dealing with a regular mouse but rather with a pointing stick (e.g. a trackpoint) so that userspace can e.g. automatically enable middle button scrollwheel emulation. It is impossible to tell the difference from the evdev info without resorting to putting a list of device / driver names in userspace, this is undesirable. Add a property which allows userspace to see if a device is a pointing stick, and set it on all the pointing stick drivers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - fix detection of touchpad on ASUS s301lHans de Goede2014-09-081-0/+7
| | | | | | | | | | Adjust Elantech signature validation to account fo rnewer models of touchpads. Cc: stable@vger.kernel.org Reported-and-tested-by: Màrius Monton <marius.monton@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - add support for trackpoint found on some v3 modelsUlrik De Bie2014-08-261-9/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <dh.herrmann@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - reset the device when elantech probe failsUlrik De Bie2014-08-261-0/+1
| | | | | | | | | | | elantech_init() calls elantech_set_absolute_mode which sets the driver in an absolute mode. When after this the elantech_init fails, it is best to turn the ps/2 mouse emulation mode back on by calling psmouse_reset() so that it can work as a regular mouse. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - don't set bit 1 of reg_10 when the no_hw_res quirk is setHans de Goede2014-06-071-2/+3
| | | | | | | | | | | | | | | | | | | | 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 <jwlademann@gmail.com> Tested-by: Philipp Wolfer <ph.wolfer@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - deal with clickpads reporting right button eventsHans de Goede2014-06-071-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <eldermarco@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - fix touchpad initialization on Gigabyte U2442Hans de Goede2014-05-051-1/+25
| | | | | | | | | | | | | | | | | | | | | | 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 <ph.wolfer@gmail.com> Tested-by: Philipp Wolfer <ph.wolfer@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - add support for newer elantech touchpadsJordan Rife2014-04-221-0/+1
| | | | | | | | | | | Newer elantech touchpads are not recognized by the current driver, since it fails to detect their firmware version number. This prevents more advanced touchpad features from being usable such as two-finger scrolling. This patch allows newer touchpads to be detected and be fully functional. Tested on Sony Vaio SVF13N17PXB. Signed-off-by: Jordan Rife <jrife0@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - improve clickpad detectionHans de Goede2013-12-181-3/+42
| | | | | | | | | | | | | | | | | | | | | | | 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 <hdegoede@redhat.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - add support for newer (August 2013) devicesMatt Walker2013-12-051-0/+1
| | | | | | | | | | | | 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 <matt.g.d.walker@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - fix packet check for v3 and v4 hardwareMatteo Delfino2013-08-241-4/+40
| | | | | | | | | | | | | | | | | | | | | | 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 <gio.frigione@gmail.com> Signed-off-by: Matteo Delfino <kendatsuba@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: elantech - fix for newer hardware versions (v7)Matteo Delfino2013-07-061-8/+9
| | | | | | | | | | | | | | | | | | | | | | * Fix version recognition in elantech_set_properties The new hardware reports itself as v7 but the packets' structure is unaltered. * Fix packet type recognition in elantech_packet_check_v4 The bitmask used for v6 is too wide, only the last three bits of the third byte in a packet (packet[3] & 0x03) are actually used to distinguish between packet types. Starting from v7, additional information (to be interpreted) is stored in the remaining bits (packets[3] & 0x1c). In addition, the value stored in (packet[0] & 0x0c) is no longer a constant but contains additional information yet to be deciphered. This change should be backwards compatible with v6 hardware. Additional-author: Giovanni Frigione <gio.frigione@gmail.com> Signed-off-by: Matteo Delfino <kendatsuba@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Input: MT - Add flags to input_mt_init_slots()Henrik Rydberg2012-09-191-2/+2
| | | | | | | | | | 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 <benjamin.tissoires@enac.fr> Tested-by: Ping Cheng <pingc@wacom.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
* Input: elantech - v4 is a clickpad, with only one buttonJJ Ding2012-04-101-2/+4
| | | | | | | | | | | | | | | 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 <louis@jachiet.com> Signed-off-by: JJ Ding <jj_ding@emc.com.tw> Reviewed-by: Chase Douglas <chase.douglas@canonical.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - reset touchpad before configuring itJJ Ding2012-04-101-0/+4
| | | | | | | | | | | | 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 <jj_ding@emc.com.tw> Reviewed-by: Chase Douglas <chase.douglas@canonical.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Merge commit 'v3.2-rc3' into nextDmitry Torokhov2011-11-291-8/+18
|\
| * Input: elantech - adjust hw_version detection logicJJ Ding2011-11-091-8/+18
| | | | | | | | | | | | | | | | | | | | | | This patch fixes some v3 hardware (fw_version: 0x150500) wrongly detected as v2 hardware. Reported-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: JJ Ding <jj_ding@emc.com.tw> Tested-By: Marc Dietrich <marvin24@gmx.de> Acked-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* | Input: elantech - add resolution query support for v4 hardwareJJ Ding2011-11-201-0/+37
| | | | | | | | | | | | | | | | | | 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 <jj_ding@emc.com.tw> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* | Input: elantech - add support for elantech fast commandJJ Ding2011-11-201-8/+28
| | | | | | | | | | | | | | | | | | Starting with v3 hardware, the firmware supports this shorter elantech_send_cmd. Teach the driver to use it. Signed-off-by: JJ Ding <jj_ding@emc.com.tw> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* | Input: convert obsolete strict_strtox to kstrtoxJJ Ding2011-11-091-5/+2
|/ | | | | | | | | | | With commit 67d0a0754455f89ef3946946159d8ec9e45ce33a we mark strict_strtox as obsolete. Convert all remaining such uses in drivers/input/. Also change long to appropriate types, and return error conditions from kstrtox separately, as Dmitry sugguests. Signed-off-by: JJ Ding <dgdunix@gmail.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: psmouse - switch to using dev_*() for messagesDmitry Torokhov2011-10-101-37/+47
| | | | | | | | | | 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 <gaowanlong@cn.fujitsu.com> Reviewed-by: JJ Ding <dgdunix@gmail.com> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - remove module parameter force_elantechJJ Ding2011-09-201-10/+2
| | | | | | | | | | | 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 <jj_ding@emc.com.tw> Reviewed-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - better support all those v2 variantsJJ Ding2011-09-201-5/+41
| | | | | | | | | | | | | | | | | 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 <jj_ding@emc.com.tw> Tested-by: Richard Schütz <r.schtz@t-online.de> Reviewed-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - add v4 hardware supportJJ Ding2011-09-091-13/+236
| | | | | | | | | 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 <jj_ding@emc.com.tw> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - add v3 hardware supportJJ Ding2011-09-091-19/+189
| | | | | | | | | | 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 <jj_ding@emc.com.tw> Acked-by: Daniel Kurtz <djkurtz@chromium.org> Acked-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - clean up elantech_initJJ Ding2011-09-091-30/+39
| | | | | | | | | Group property setting code into elantech_set_properties. Signed-off-by: JJ Ding <jj_ding@emc.com.tw> Acked-by: Daniel Kurtz <djkurtz@chromium.org> Acked-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - packet checking for v2 hardwareJJ Ding2011-09-091-5/+34
| | | | | | | | | | | | | For v2 hardware, there is no real parity check, but we can still check some constant bits for data integrity. Also rename elantech_check_parity_v1 to elantech_packet_check_v1 to make these packet checking function names consistent. Signed-off-by: JJ Ding <jj_ding@emc.com.tw> Acked-by: Daniel Kurtz <djkurtz@chromium.org> Acked-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - use firmware provided x, y rangesJJ Ding2011-09-091-15/+56
| | | | | | | | | | With newer hardware, the touchpad provides range info. Let's use it. Signed-off-by: JJ Ding <jj_ding@emc.com.tw> Acked-by: Daniel Kurtz <djkurtz@chromium.org> Acked-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - get rid of ETP_2FT_* in elantech.hJJ Ding2011-09-091-15/+13
| | | | | | | | | | | | | | For two finger touches the coordinate of each finger gets reported separately but with reduced resolution. With this change, we now have the same range for ST and MT data and scale MT data because it has lower resolution to match ST. Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: JJ Ding <jj_ding@emc.com.tw> Acked-by: Daniel Kurtz <djkurtz@chromium.org> Acked-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - correct x, y value range for v2 hardwareJJ Ding2011-09-091-4/+4
| | | | | | | | | | x, y values are actually 12-bit long. Also update protocol document to reflect the change. Signed-off-by: JJ Ding <jj_ding@emc.com.tw> Acked-by: Daniel Kurtz <djkurtz@chromium.org> Acked-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - remove support for proprietary X driverÉric Piel2011-05-161-12/+0
| | | | | | | | | | | | | Apparently somewhere someone had a proprietary X driver. To get the multitouch info, it uses some hack on the normal API instead of using the multitouch protocol. Now that the multitouch info is transmitted correctly it makes not much sense to keep it. Especially because it's impossible to find this proprietary X driver anywhere, so the number of users must be very low. Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net> Reviewed-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - report multitouch with proper ABS_MT messagesÉric Piel2011-05-161-5/+34
| | | | | | | | | | | | | | | | | Multitouch info was reported only via a old protocol used by the proprietary X driver from elantech. Let's report the multitouch info also following the official MT protocol. It's semi-mt because the device only reports the lowest/highest coordinates. This was done following the multi-touch-protocol.txt documentation, and inspired by the bcm5974 and elantech implementations. Testing was light as there is not many applications using this protocol yet, but the X synaptics driver didn't complain and the X multitouch driver behaved correctly. Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net> Reviewed-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - export pressure and width when supportedÉric Piel2011-05-161-1/+22
| | | | | | | | | | Using the info of the Dell/Ubuntu driver, described in the protocol document, report both width and pressure when pressing 1 and 3 fingers, for the versions of the touchpad which support it. Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net> Reviewed-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: return -ENOMEM in select drivers when memory allocation failsDavidlohr Bueso2010-10-131-1/+1
| | | | | | | Instead of using -1 let's start using proper error codes. Signed-off-by: Davidlohr Bueso <dave@gnu.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - report position also with 3 fingersÉric Piel2010-08-051-0/+10
| | | | | | | | | | The 6-byte protocol supports reporting the position when three fingers are pressed, exactly like when one finger is pressed. Report this. In addition, it is also distinguishes between 3 and 4 fingers pressed. Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - discard the first 2 positions on some firmwaresÉric Piel2010-08-051-11/+10
| | | | | | | | | | | According to the Dell/Ubuntu driver, what was previously observed as "jumpy cursor" corresponds to the hardware sending incorrect data for the first two reports of a one touch finger. So let's use the same workaround as in the other driver. Also, detect another firmware version with the same behaviour, as in the other driver. Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - relax signature checksDmitry Torokhov2010-05-191-1/+19
| | | | | | | | | | Apparently there are Elantech touchpads that report non-zero in the 2nd byte of their signature. Adjust the detection routine so that if 2nd byte is zero and 3rd byte contains value that is not a valid report rate, we still assume that signature is valid. Tested-by: Eric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* Input: elantech - enforce common prefix on messagesDmitry Torokhov2010-05-191-35/+32
| | | | Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
OpenPOWER on IntegriCloud