When KBC is in active multiplexing mode the touchpad on this laptop does
not work.
Reported-by: Bilal Koc <koc.bilo@googlemail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

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>

On some laptops, keyboard needs to be reset in order to successfully detect
touchpad (e.g., some Gigabyte laptop models with Elantech touchpads).
Without resettin keyboard touchpad pretends to be completely dead.

Based on the original patch by Mateusz Jończyk this version has been
expanded to include DMI based detection & application of the fix
automatically on the affected models of laptops. This has been confirmed to
fix problem by three users already on three different models of laptops.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81331
Cc: stable@vger.kernel.org
Signed-off-by: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Tested-by: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
Tested by: Zakariya Dehlawi <zdehlawi@gmail.com>
Tested-by: Guillaum Bouchard <guillaum.bouchard@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

I am using gmail.com exclusively and mail.ru was a backup that so far was
not needed. To avoid getting 2 copies of the same message let's drop
mail.ru from MAINTAINERS file.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The successive init_completion calls should be reinit_completion calls.
Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
Acked-by: Helge Deller <deller@gmx.de>
Tested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Second round of input updates for 3.19.

Add a table documenting where all the bits are in the v7 touchpad packets.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Hans de Goede <hdegoede@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry 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: Hans de Goede <hdegoede@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry 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: Hans de Goede <hdegoede@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This patch adds support for CLOCK_BOOTTIME for input event timestamp.
CLOCK_BOOTTIME includes suspend time, so it would allow aplications
to get correct time difference between two events even when system
resumes from suspend state.
Signed-off-by: Aniroop Mathur <a.mathur@samsung.com>
Signed-off-by: Dmitry 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: Mike Murdoch <main.haarp@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

All keypad column pins used as inputs should be pulled up on the STMPE24xx,
but this is not done by the current driver.  Add some logic that will do
this properly. The STMPE1601 also has a keypad controller, but explicitly
does *NOT* require you to set up any pull-ups.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The STMPE keypad controller is only used with device tree configured
systems, so force the configuration to come from device tree only, and now
actually get the rows and cols from the device tree too.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This adds the register offsets for pull up/down for the STMPE
1601, 1801 and 24xx expanders. This is used to bias GPIO lines
and keypad lines.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This patch avoids unnecessary operations while estimating events per
packet for an input device when event type is not set.
Signed-off-by: Anshul Garg <anshul.g@samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Fixed a coding style error, macros with complex values should be
enclosed in parentheses.
Signed-off-by: Asaf Vertz <asaf.vertz@tandemg.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We do not need to roll our own implementation of delayed work now that we
have proper implementation of mod_delayed_work.

For interrupt-only driven buttons we retain the timer, but we rename
it to release_timer to better reflect its purpose.
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This change allows specify interrupt for buttons separately form gpio,
potentially allowing to form several "clusters" of buttons on
different interrupts.

Button defined without both gpio and irq in device tree is a hared error
instead of a warning now.
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Prepare input updates for 3.19.

Commit af906faa ("Input: gpio_keys - fix warning regarding uninitialized
'irq' variable") introduced the following build warning:

drivers/input/keyboard/gpio_keys.c:625:16: warning: 'button' may be used uninitialized in this function [-Wmaybe-uninitialized]

Move the 'button' initialization to a proper location to avoid such warning.
Reported-by: Olof's autobuilder <build@lixom.net>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This driver supports Elan eKTH I2C touchscreen controllers. Note that these
are using custom protocol, as opposed to other Elan parts that use
HID-over-I2C and are supported by the standard HID-multitouch driver.
Signed-off-by: Scott Liu <scott.liu@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Commit f2d347ff ("Input: gpio_keys - add device tree support for
interrupt only keys") caused the following build warning:

drivers/input/keyboard/gpio_keys.c: In function 'gpio_keys_probe':
drivers/input/keyboard/gpio_keys.c:647:15: warning: 'irq' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/input/keyboard/gpio_keys.c:622:7: note: 'irq' was declared here

Move button->irq initialization into proper branch and get rid of the
temporary.
Reported-by: Olof's autobuilder <build@lixom.net>
Reported-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Let's use 'error' variable instead of 'ret' when we need to store erro
codes.
Signed-off-by: Dudley Du <dudley.dulixin@gmail.com>
Signed-off-by: Dmitry 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: Jeremiah Mahler <jmmahler@gmail.com>
Signed-off-by: Dudley Du <dudley.dulixin@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This features already exists for board config setups. Add support for
device tree based systems.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Allocate the temporary buffer needed for initialization of the console
keyboard maps (512 bytes, as NR_KEYS = 256) on the stack instead of
statically, to reduce kernel size.

add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-512 (-512)
function                                     old     new   delta
temp_map                                     512       -    -512
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

If CONFIG_HW_CONSOLE is not set:

drivers/built-in.o: In function `amikbd_probe':
amikbd.c:(.init.text+0x3e4e): undefined reference to `key_maps'
amikbd.c:(.init.text+0x3dd4): undefined reference to `key_maps'

To fix this, extract the initialization of the console keyboard maps
into amikbd_init_console_keymaps(), protected by #ifdef
CONFIG_HW_CONSOLE.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The missing error handling here is not especially harmful but static
checkers complain that "i" can be used uninitialized.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Let's initialize atomic_t variables keeping track of number of various
devices created so far with -1 in order to avoid extra subtraction
operation.
Signed-off-by: Aniroop Mathur <aniroop.mathur@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Let's initializes input_no to -1 in order to avoid extra subtraction
operation performed every time we allocate an input device.
Signed-off-by: Aniroop Mathur <aniroop.mathur@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The Intel NUC D54250WYK has no PS/2 controller, however the DSDT declares
PS/2 devices which trigger the loading of the i8042 driver.
Signed-off-by: Todor Minchev <todor.minchev@intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The xpad wireless endpoint is not a bulk endpoint on my devices, but
rather an interrupt one, so the USB core complains when it is submitted.
I'm guessing that the author really did mean that this should be an
interrupt urb, but as there are a zillion different xpad devices out
there, let's cover out bases and handle both bulk and interrupt
endpoints just as easily.
Signed-off-by: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Dmitry 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: Marcus Overhagen <marcus.overhagen@gmail.com>
Reported-and-tested-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Without the change either no scancode would be reported on release of
force_release keys, or - if the key is marked as force_release erroneously
- the release event and the scancode would be reported in separate reports
to the input layer.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Dmitry 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: Binyamin Sagal <bensagal@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

A chapter is added to describe the trackpoint packets.

A section is added to describe the behaviour of the knob crc_enabled in
sysfs.

The introduction of the documentation only mentioned v1/v2, but in the
last part it already contains explanation of v3 and v4. The introduction
is updated.
Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org>
Signed-off-by: Dmitry 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: 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>

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>

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: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Pali Rohár <pali.rohar@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>