user/sven/linux.git/drivers/input, branch v3.2.78

Input: i8042 - add Fujitsu Lifebook U745 to the nomux list

2016-02-13T10:34:07Z

commit dd0d0d4de582a6a61c032332c91f4f4cb2bab569 upstream. Without i8042.nomux=1 the Elantech touch pad is not working at all on a Fujitsu Lifebook U745. This patch does not seem necessary for all U745 (maybe because of different BIOS versions?). However, it was verified that the patch does not break those (see opensuse bug 883192: https://bugzilla.opensuse.org/show_bug.cgi?id=883192). Signed-off-by: Aurélien Francillon Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

Input: evdev - do not report errors form flush()

2015-10-13T02:46:08Z

commit eb38f3a4f6e86f8bb10a3217ebd85ecc5d763aae upstream. We've got bug reports showing the old systemd-logind (at least system-210) aborting unexpectedly, and this turned out to be because of an invalid error code from close() call to evdev devices. close() is supposed to return only either EINTR or EBADFD, while the device returned ENODEV. logind was overreacting to it and decided to kill itself when an unexpected error code was received. What a tragedy. The bad error code comes from flush fops, and actually evdev_flush() returns ENODEV when device is disconnected or client's access to it is revoked. But in these cases the fact that flush did not actually happen is not an error, but rather normal behavior. For non-disconnected devices result of flush is also not that interesting as there is no potential of data loss and even if it fails application has no way of handling the error. Because of that we are better off always returning success from evdev_flush(). Also returning EINTR from flush()/close() is discouraged (as it is not clear how application should handle this error), so let's stop taking evdev->mutex interruptibly. Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=939834 Signed-off-by: Takashi Iwai Signed-off-by: Dmitry Torokhov [bwh: Backported to 3.2: there's no revoked flag to test] Signed-off-by: Ben Hutchings

Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen

2015-08-12T14:33:23Z

commit 968491709e5b1aaf429428814fff3d932fa90b60 upstream. This patch fixes a problem in the usbtouchscreen driver for DMC TSC-30 touch screen. Due to a missing delay between the RESET and SET_RATE commands, the touch screen may become unresponsive during system startup or driver loading. According to the DMC documentation, a delay is needed after the RESET command to allow the chip to complete its internal initialization. As this delay is not guaranteed, we had a system where the touch screen occasionally did not send any touch data. There was no other indication of the problem. The patch fixes the problem by adding a 150ms delay between the RESET and SET_RATE commands. Suggested-by: Jakob Mustafa Signed-off-by: Bernhard Bender Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

Input: elantech - add new icbody type

2015-08-06T23:32:15Z

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: Ben Hutchings

Input: elantech - support new ICs types for version 4

2015-08-06T23:32:15Z

commit 810aa0918b2b032684c8cad13f73d6ba37ad11c0 upstream. This change allows the driver to recognize newer Elantech touchpads. Signed-off-by: Yi ju Hong Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

Input: elantech - add support for newer elantech touchpads

2015-08-06T23:32:15Z

commit ae4bedf0679d99f0a9b80a7ea9b8dd205de05d06 upstream. 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 Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

Input: elantech - add support for newer (August 2013) devices

2015-08-06T23:32:14Z

commit 9cb80b965eaf7af1369f6e16f48a05fbaaccc021 upstream. 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 Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

Input: elantech - fix for newer hardware versions (v7)

2015-08-06T23:32:14Z

commit 9eebed7de660c0b5ab129a9de4f89d20b60de68c upstream. * 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 Signed-off-by: Matteo Delfino Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

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

2015-08-06T23:32:14Z

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: Ben Hutchings

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

2015-08-06T23:32:11Z

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: Ben Hutchings