The Fimware 8.1 has a bug in which the extra buttons are only sent when the
ExtBit is 1.  This should be fixed in a future FW update which should have
a bump of the minor version.

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

On the X1 Carbon 3rd gen (with a 2015 broadwell cpu), the physical middle
button of the trackstick (attached to the touchpad serio device, of course)
seems to get lost.

Actually, the touchpads reports 3 extra buttons, which falls in the switch
below to the '2' case. Let's handle the case of odd numbers also, so that
the middle button finds its way back.

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

Post-2013 Lenovo laptops provide correct min/max dimensions, which are
different with the ones currently quirked.  According to
https://bugzilla.kernel.org/show_bug.cgi?id=91541 the following board ids
are assigned in the post-2013 touchpads:

t440p/t440s: LEN0036 -> 2964/2962
t540p:       LEN0034 -> 2964

Using 2961 as the common minimum makes these 3 laptops OK. We may need
to update those values later if other pnp_ids has a lower board_id.

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

Add a min/max range for board ids to the min/max coordinates quirk. This
makes it possible to restrict quirks to specific models based upon their
board id. The define ANY_BOARD_ID (0) serves as a wild card.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Martin <daniel.martin@secunet.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The firmware of the X240 (LEN0035, 2013/12) exposes the same values
    x [1232..5710], y [1156..4696]
as the quirk applies.

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Martin <consume.noise@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Query the min dimensions even if the check
SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 7 fails, but we know that the
firmware version 8.1 is safe.

With that we don't need quirks for post-2013 models anymore as they expose
correct min and max dimensions.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Martin <consume.noise@gmail.com>
  re-order the tests to check SYN_CAP_MIN_DIMENSIONS even on FW 8.1
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Logging the dimension values we queried and the values we use from a quirk
to overwrite can be helpful for debugging.

This partly relates to bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=91541

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Martin <consume.noise@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Split the function synaptics_resolution() into synaptics_resolution() and
synaptics_quirks().  synaptics_resolution() will be called before
synaptics_quirks() to query dimensions and resolutions before overwriting
them with quirks.

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Martin <consume.noise@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
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>

LEN0037 found in the Lenovo ThinkPad X1 Carbon 2nd (2014 model)

Cc: stable@vger.kernel.org
Reported-and-tested-by: NBjoern Olausson <bjoern@olausson.de>
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
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>

Add a table documenting where all the bits are in the v7 touchpad packets.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Protocol v7 uses the middle / right button bits on clickpads to communicate
"location" information of a 3th touch (and possible 4th) touch on
clickpads.

Specifically when 3 touches are down, if one of the 3 touches is in the
left / right button area, this will get reported in the middle / right
button bits and the touchpad will still send a TWO type packet rather then
a MULTI type packet, so when this happens we must add the finger reported
in the button area to the finger count.

Likewise we must also add fingers reported this way to the finger count
when we get MULTI packets.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338
Cc: stable@vger.kernel.org # 3.17
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The v7 proto differentiates between a primary touch (with high precision)
and a secondary touch (with lower precision). Normally when 2 fingers are
down and one is lifted the still present touch becomes the primary touch,
but some traces have shown that this does not happen always.

This commit deals with this by making alps_get_mt_count() not stop at the
first empty mt slot, and if a touch is present in mt[1] and not mt[0]
moving the data to mt[0] (for input_mt_assign_slots).

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338
Cc: stable@vger.kernel.org # 3.17
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

NEW packets are send to indicate a discontinuity in the finger coordinate
reporting. Specifically a finger may have moved from slot 0 to 1 or vice
versa.  INPUT_MT_TRACK takes care of this for us.

NEW packets have 3 problems:
1) They do not contain middle / right button info (on non clickpads)
   this can be worked around by preserving the old button state
2) They do not contain an accurate fingercount, and they are
   typically send when the number of fingers changes. We cannot use
   the old finger count as that may mismatch with the amount of
   touch coordinates we've available in the NEW packet
3) Their x data for the second touch is inaccurate leading to
   a possible jump of the x coordinate by 16 units when the first
   non NEW packet comes in

Since problems 2 & 3 cannot be worked around, just ignore them.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338
Cc: stable@vger.kernel.org # 3.17
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

IBM Trackpoints have a feature to compensate for drift by recalibrating
themselves periodically. By default, if for 0.5 seconds there is no change
in position, it's used as the new zero. This duration is too low. Often,
the calibration happens when the trackpoint is in fact being used.

IBM's Trackpoint Engineering Specifications show a configuration register
that allows changing this duration, rstdft1.

Expose it via sysfs among the other settings.
Signed-off-by: NMike Murdoch <main.haarp@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Let's use 'error' variable instead of 'ret' when we need to store erro
codes.
Signed-off-by: NDudley Du <dudley.dulixin@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Chage b1cfa7b4 tried to get away form using
irq in cyapa structure and use client->irq instead, but missed a couple of
spots making the touchpad inoperative after resume.
Reported-by: NJeremiah Mahler <jmmahler@gmail.com>
Signed-off-by: NDudley Du <dudley.dulixin@gmail.com>
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 LEN2006 Synaptics touchpad (as found in Thinkpad E540) returns wrong
min max values.

touchpad-edge-detector output:
>  Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event6
>  Move one finger around the touchpad to detect the actual edges
>  Kernel says:    x [1472..5674], y [1408..4684]
>  Touchpad sends: x [1264..5675], y [1171..4688]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88211
Cc: stable@vger.kernel.org
Signed-off-by: NBinyamin Sagal <bensagal@gmail.com>
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>

Sometimes on Dell Latitude laptops psmouse/alps driver receive invalid ALPS
protocol V3 packets with bit7 set in last byte. More often it can be
reproduced on Dell Latitude E6440 or E7440 with closed lid and pushing
cover above touchpad.

If bit7 in last packet byte is set then it is not valid ALPS packet. I was
told that ALPS devices never send these packets. It is not know yet who
send those packets, it could be Dell EC, bug in BIOS and also bug in
touchpad firmware...

With this patch alps driver does not process those invalid packets, but
instead of reporting PSMOUSE_BAD_DATA, getting into out of sync state,
getting back in sync with the next byte and spam dmesg we return
PSMOUSE_FULL_PACKET. If driver is truly out of sync we'll fail the checks
on the next byte and report PSMOUSE_BAD_DATA then.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NPali Rohár <pali.rohar@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Use of managed resources simplifies error handling and device removal code.
Signed-off-by: NDudley Du <dudl@cypress.com>
[Dmitry: added open/close methods so cyapa_remove is no longer needed.]
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

For functions defined in header files we should use static inline rather
than inline, which breaks under the latest upstream gcc (which is really
gcc issue, but static inline is better suited regardless).

The related error (with allmodconfig under tile):

    MODPOST 4002 modules
  ERROR: "lifebook_detect" [drivers/input/mouse/psmouse.ko] undefined!
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On some Dell Latitude laptops ALPS device or Dell EC send one invalid byte
in 6 bytes ALPS packet. In this case psmouse driver enter out of sync
state. It looks like that all other bytes in packets are valid and also
device working properly. So there is no need to do full device reset, just
need to wait for byte which match condition for first byte (start of
packet). Because ALPS packets are bigger (6 or 8 bytes) default limit is
small.

This patch increase number of invalid bytes to size of 2 ALPS packets which
psmouse driver can drop before do full reset.

Resetting ALPS devices take some time and when doing reset on some Dell
laptops touchpad, trackstick and also keyboard do not respond. So it is
better to do it only if really necessary.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NPali Rohár <pali.rohar@gmail.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

5th and 6th byte of ALPS trackstick V3 protocol match condition for first
byte of PS/2 3 bytes packet. When driver enters out of sync state and ALPS
trackstick is sending data then driver match 5th, 6th and next 1st bytes as
PS/2.

It basically means if user is using trackstick when driver is in out of
sync state driver will never resync. Processing these bytes as 3 bytes PS/2
data cause total mess (random cursor movements, random clicks) and make
trackstick unusable until psmouse driver decide to do full device reset.

Lot of users reported problems with ALPS devices on Dell Latitude E6440,
E6540 and E7440 laptops. ALPS device or Dell EC for unknown reason send
some invalid ALPS PS/2 bytes which cause driver out of sync. It looks like
that i8042 and psmouse/alps driver always receive group of 6 bytes packets
so there are no missing bytes and no bytes were inserted between valid
ones.

This patch does not fix root of problem with ALPS devices found in Dell
Latitude laptops but it does not allow to process some (invalid)
subsequence of 6 bytes ALPS packets as 3 bytes PS/2 when driver is out of
sync.

So with this patch trackstick input device does not report bogus data when
also driver is out of sync, so trackstick should be usable on those
machines.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NPali Rohár <pali.rohar@gmail.com>
Cc: stable@vger.kernel.org
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
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>

The new Lenovo T440s laptop has a different PnP ID "LEN0039", and it
needs the similar min/max quirk to make its clickpad working.

BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=903748Reported-and-tested-by: NJoschi Brauchle <joschibrauchle@gmx.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Use __maybe_unused instead of ifdef guards around suspend/resume
functions, in order to increase build coverage and fix build warnings.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

psmouse_reconnect() will not be called if psmouse driver is not bound to
the serio port, so there is no point in checking that.  Also, as coded, it
introduces potential NULL dereference in psmouse_dbg() in case psmouse is
indeed NULL. Let's just remove it.

Detected by Coverity: CID 146528
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

I believe the intent of the code was to drop oldest bytes from the queue,
not the latest if we drop one byte and both latest and some oldest of we
are dropping more than one.
Acked-by: NJan-Benedict Glaw <jbglaw@lug-owl.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This driver supports Elan I2C/SMbus touchpads found in some laptops and
also in many Chromebooks.
Signed-off-by: NDuson Lin <dusonlin@emc.com.tw>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Since the change to struct input_mt_pos some variables are now bitfields
instead of integers. Automatic conversion from integer to bitfield entry
destroys information, therefore enforce boolean interpretation instead.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1114768
Fixes: 02d04254 ("Input: alps - use struct input_mt_pos to track coordinates")
Signed-off-by: NAndreas Bosch <linux@progandy.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Unfortunately, ForcePad capability is not actually exported over PS/2, so
we have to resort to DMI checks.

Cc: stable@vger.kernel.org
Reported-by: NNicole Faerber <nicole.faerber@kernelconcepts.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The Asus X450 and X550 laptops use a PS/2 touchpad from a new
manufacturer called FocalTech:

https://bugzilla.kernel.org/show_bug.cgi?id=77391
https://bugzilla.redhat.com/show_bug.cgi?id=1110011

The protocol for these devices is not known at this time, but even
without knowing the protocol they need some special handling. They get
upset by some of our other PS/2 device probing, and once upset generate
random mouse events making things unusable even with an external mouse.

This patch adds detection of these devices based on their pnp ids, and
when they are detected, treats them as a bare ps/2 mouse. Doing things
this way they at least work in their ps/2 mouse emulation mode.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The matches_pnp_id function from the synaptics driver is useful for other
drivers too. Make it a generic psmouse helper function.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of
physical buttons, instead they generate primary button click when user
presses somewhat hard on the surface of the touchpad. Unfortunately they
also report primary button click whenever there are 2 or more contacts
on the pad, messing up all multi-finger gestures (2-finger scrolling,
multi-finger tapping, etc). To cope with this behavior we introduce a
delay (currently 50 msecs) in reporting primary press in case more
contacts appear.

Cc: stable@vger.kernel.org
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>