kernel/linux.git/drivers/input, branch v4.0.8

Input: elantech - add new icbody type

2015-06-23T00:03:28+00:00

commit 692dd1916436164e228608803dfb6cb768d6355a upstream. This adds new icbody type to the list recognized by Elantech PS/2 driver. Signed-off-by: Sam Hung Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: elantech - fix detection of touchpads where the revision matches a known rate

2015-06-23T00:03:28+00:00

commit 5f0ee9d17aae628b22be86966471db65be21f262 upstream. 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. Reported-and-tested-by: David Zafra Gómez Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: synaptics - add min/max quirk for Lenovo S540

2015-06-23T00:03:28+00:00

commit 7f2ca8b55aeff1fe51ed3570200ef88a96060917 upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1223051#c2 Tested-by: tommy.gagnes@gmail.com Signed-off-by: Peter Hutterer Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: alps - do not reduce trackpoint speed by half

2015-06-23T00:03:28+00:00

commit 088df2ccef75754cc16a6ba31829d23bcb2b68ed upstream. On some v7 devices (e.g. Lenovo-E550) the deltas reported are typically only in the 0-1 range dividing this by 2 results in a range of 0-0. And even for v7 devices where this does not lead to making the trackstick entirely unusable, it makes it twice as slow as before we added v7 support and were using the ps/2 mouse emulation of the dual point setup. If some kind of generic slowdown is actually necessary for some devices, then that belongs in userspace, not in the kernel. Reported-and-tested-by: Rico Moorman Signed-off-by: Hans de Goede Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: elantech - fix semi-mt protocol for v3 HW

2015-06-06T15:21:07+00:00

commit 3c0213d17a09601e0c6c0ae0e27caf70d988290f upstream. 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 Signed-off-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: alps - fix touchpad buttons getting stuck when used with trackpoint

2015-05-06T20:03:49+00:00

commit 6bcca19f5dcedc3a006ca0bcc3699a437cadee74 upstream. When the left touchpad button gets pressed, and then the trackpoint is moved, and then the button is released, the following happens: 1) touchpad packet is received, touchpad evdev node reports BTN_LEFT 1 2) pointing stick packet is received, the hw will report a BTN_LEFT 1 in this packet because when the trackstick is active it communicates the combined touchpad + pointing stick buttons in the trackstick packet, since alps_report_bare_ps2_packet passes NULL (*) for the dev2 parameter to alps_report_buttons the combining is not detected and the pointing stick evdev node will also report BTN_LEFT 1 3) on release of the button a pointing stick packet with BTN_LEFT 0 is received and the pointing stick evdev node will report BTN_LEFT 0 Note how because of the passing as NULL for dev2 the touchpad evdev node will never send BTN_LEFT 0 in this scenario leading to a stuck mouse button. This is a regression in 4.0 introduced by commit 04aae283ba6a8 ("Input: ALPS - do not mix trackstick and external PS/2 mouse data") This commit fixes this by passing in the touchpad evdev as dev2 parameter when calling alps_report_buttons for the pointingstick on alps v2 devices, so that alps_report_buttons correctly detect that we're already reporting the button as pressed via the touchpad evdev node, and will also send the release event there. Reported-by: Hans de Bruin Signed-off-by: Hans de Goede Acked-by: Pali Rohár Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

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

2015-05-06T20:03:49+00:00

commit bd884149aca61de269fd9bad83fe2a4232ffab21 upstream. 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 Reported-and-tested-by: George Moutsopoulos Signed-off-by: Ulrik De Bie Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

2015-04-06T21:10:08+00:00

Pull input fixes from Dmitry Torokhov: "Updates for the input subsystem - two more tweaks for ALPS driver to work out kinks after splitting the touchpad, trackstick, and potential external PS/2 mouse into separate input devices. Changes to support ALPS SS4 devices (protocol V8) will be coming in 4.1..." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: alps - document stick behavior for protocol V2 Input: alps - report V2 Dualpoint Stick events via the right evdev node Input: alps - report interleaved bare PS/2 packets via dev3

Input: alps - report V2 Dualpoint Stick events via the right evdev node

2015-04-05T18:48:35+00:00

On V2 devices the DualPoint Stick reports bare packets, these should be reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also has the INPUT_PROP_POINTING_STICK propbit set. Note that since there is no way to distinguish these packets from an external PS/2 mouse (insofar as these laptops have an external PS/2 port) this means that we will be reporting PS/2 mouse events via this evdev node too, as we've been doing in kernel 3.19 and older. This has been tested on a Dell Latitude D620 and a Dell Latitude E6400, which both have a V2 touchpad + a DualPoint Stick which reports bare packets. Signed-off-by: Hans de Goede Reviewed-by: Pali Rohár Signed-off-by: Dmitry Torokhov

Input: alps - report interleaved bare PS/2 packets via dev3

2015-04-05T18:48:34+00:00

Bare packets should be reported via the same evdev device independent on whether they are detected on the beginning of a packet or in the middle of a packet. This has been tested on a Dell Latitude E6400, where the DualPoint Stick reports bare packets, which get reported via dev3 when the touchpad is idle, and via dev2 when the touchpad and stick are used simultaneously. This commit fixes this inconsistency by always reporting bare packets via dev3. Note that since the come from a DualPoint Stick they really should be reported via dev2, this gets fixed in a later commit. Signed-off-by: Hans de Goede Reviewed-by: Pali Rohár Signed-off-by: Dmitry Torokhov