The touchpad in HP Pavilion 14-ab057ca reports it's version as 12 and
according to Elan both 11 and 12 are valid IC types and should be
identified as hw_version 4.
Reported-by: NPatrick Lessard <Patrick.Lessard@cogeco.com>
Tested-by: NPatrick Lessard <Patrick.Lessard@cogeco.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This patch changes name of secondary psmouse devices to mach format of
primary device. Format of primary device is "protocol vendor name" and is
set by function psmouse_switch_protocol() in file psmouse-base.c.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When using a protocol v2 or v3 hardware, elantech uses the function
elantech_report_semi_mt_data() to report data. This devices are rather
creepy because if num_finger is 3, (x2,y2) is (0,0). Yes, only one valid
touch is reported.

Anyway, userspace (libinput) is now confused by these (0,0) touches,
and detect them as palm, and rejects them.

Commit 3c0213d1 ("Input: elantech - fix semi-mt protocol for v3 HW")
was sufficient enough for xf86-input-synaptics and libinput before it has
palm rejection. Now we need to actually tell libinput that this device is
a semi-mt one and it should not rely on the actual values of the 2 touches.

Cc: stable@vger.kernel.org
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Another Lifebook machine that needs the same quirk as other similar
models to make the driver working.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=883192
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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 <dusonlin@emc.com.tw>
Reviewed-by: NUlrik De Bie <ulrik.debie-os@e2big.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

All Elantech touchpads pre-v4 with dynamic resolution queries have a fixed
resolution of 800dpi -> 31.49 units/mm. Set this statically, so userspace
does not have to guess.
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This adds new icbody type to the list recognized by Elantech PS/2 driver.

Cc: stable@vger.kernel.org
Signed-off-by: NSam Hung <sam.hung@emc.com.tw>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NDavid Zafra Gómez <dezeta@klo.es>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NGeorge Moutsopoulos <gmoutso@yahoo.co.uk>
Signed-off-by: NUlrik De Bie <ulrik.debie-os@e2big.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NRainer Koenig <Rainer.Koenig@ts.fujitsu.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This change allows the driver to recognize newer Elantech touchpads.

Cc: stable@vger.kernel.org
Signed-off-by: NYi ju Hong <sam.hung@emc.com.tw>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Only try to parse data as coming from trackpoint if firmware told us that
trackpoint is present.

Fixes commit caeb0d37Reported-and-tested-by: NMarcus Overhagen <marcus.overhagen@gmail.com>
Reported-and-tested-by: NAnders Kaseorg <andersk@mit.edu>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NStefan Valouch <stefan@valouch.com>
Signed-off-by: NUlrik De Bie <ulrik.debie-os@e2big.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NStefan Valouch <stefan@valouch.com>
Signed-off-by: NUlrik De Bie <ulrik.debie-os@e2big.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NStefan Valouch <stefan@valouch.com>
Tested-by: NStefan Valouch <stefan@valouch.com>
Tested-by: NAlfredo Gemma <alfredo.gemma@gmail.com>
Signed-off-by: NUlrik De Bie <ulrik.debie-os@e2big.org>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The Fujitsu H730 has hardware v4 with a trackpoint. This enables the
elantech_report_trackpoint for v4.
Reported-by: NStefan Valouch <stefan@valouch.com>
Tested-by: NStefan Valouch <stefan@valouch.com>
Tested-by: NAlfredo Gemma <alfredo.gemma@gmail.com>
Signed-off-by: NUlrik De Bie <ulrik.debie-os@e2big.org>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NHans de Goede <hdegoede@redhat.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Adjust Elantech signature validation to account fo rnewer models of
touchpads.

Cc: stable@vger.kernel.org
Reported-and-tested-by: NMàrius Monton <marius.monton@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NUlrik De Bie <ulrik.debie-os@e2big.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NUlrik De Bie <ulrik.debie-os@e2big.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NJames Lademann <jwlademann@gmail.com>
Tested-by: NPhilipp Wolfer <ph.wolfer@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NElder Marco <eldermarco@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NPhilipp Wolfer <ph.wolfer@gmail.com>
Tested-by: NPhilipp Wolfer <ph.wolfer@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NJordan Rife <jrife0@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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:

9eebed7d
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: NGiovanni Frigione <gio.frigione@gmail.com>
Signed-off-by: NMatteo Delfino <kendatsuba@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

* 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: NMatteo Delfino <kendatsuba@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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: NBenjamin Tissoires <benjamin.tissoires@enac.fr>
Tested-by: NPing Cheng <pingc@wacom.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>

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: NJachiet Louis <louis@jachiet.com>
Signed-off-by: NJJ Ding <jj_ding@emc.com.tw>
Reviewed-by: NChase Douglas <chase.douglas@canonical.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

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: NJJ Ding <jj_ding@emc.com.tw>
Reviewed-by: NChase Douglas <chase.douglas@canonical.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

It turns out that v4's firmware provides a command so we can query
the resolution. Let's use it.
Signed-off-by: NJJ Ding <jj_ding@emc.com.tw>
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Starting with v3 hardware, the firmware supports this shorter
elantech_send_cmd. Teach the driver to use it.
Signed-off-by: NJJ Ding <jj_ding@emc.com.tw>
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

With commit 67d0a075 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: NJJ Ding <dgdunix@gmail.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

This patch fixes some v3 hardware (fw_version: 0x150500) wrongly detected
as v2 hardware.
Reported-by: NMarc Dietrich <marvin24@gmx.de>
Signed-off-by: NJJ Ding <jj_ding@emc.com.tw>
Tested-By: NMarc Dietrich <marvin24@gmx.de>
Acked-by: NÉric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

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: NWanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: NJJ Ding <dgdunix@gmail.com>
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

This essentially reverts commit f81bc788.

With recent work on elantech driver, I believe we now have complete support
for all elantech touchpads. So remove this hack.
Signed-off-by: NJJ Ding <jj_ding@emc.com.tw>
Reviewed-by: NÉric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

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: NJJ Ding <jj_ding@emc.com.tw>
Tested-by: NRichard Schütz <r.schtz@t-online.de>
Reviewed-by: NÉric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>