linux-stable.git/drivers/input, branch linux-2.6.32.y

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

2015-12-05T23:49:09+00:00

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 
(cherry picked from commit a6706174cfe9fa100651b5012aec9796006a884b)

Signed-off-by: Willy Tarreau

Input: elantech - discard the first 2 positions on some firmwares

2011-05-09T22:55:08+00:00

commit 7f29f17b57255b6395046805a98bc663ded63fb8 upstream.

According to the Dell/Ubuntu driver, what was previously observed as
"jumpy cursor" corresponds to the hardware sending incorrect data for
the first two reports of a one touch finger. So let's use the same
workaround as in the other driver. Also, detect another firmware
version with the same behaviour, as in the other driver.

Signed-off-by: Éric Piel 
Signed-off-by: Dmitry Torokhov 
[bwh: Adjust for 2.6.32]
Signed-off-by: Greg Kroah-Hartman

Input: elantech - relax signature checks

2011-05-09T22:55:07+00:00

commit a083632eaf6231162b33e40561cfec6a9c156945 upstream.

Apparently there are Elantech touchpads that report non-zero in the 2nd byte
of their signature. Adjust the detection routine so that if 2nd byte is
zero and 3rd byte contains value that is not a valid report rate, we still
assume that signature is valid.

Tested-by: Eric Piel 
Signed-off-by: Dmitry Torokhov 
[bwh: Adjust context for 2.6.32]
Signed-off-by: Greg Kroah-Hartman

Input: elantech - use all 3 bytes when checking version

2011-05-09T22:55:06+00:00

commit 504e8beed161bd11a2c6cbb8aaf352c14d39b5bb upstream.

Apparently all 3 bytes returned by ETP_FW_VERSION_QUERY are significant
and should be taken into account when matching hardware version/features.

Tested-by: Eric Piel 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: elantech - ignore high bits in the position coordinates

2011-05-09T22:55:06+00:00

commit e938fbfd4a7ac829d48b767c4dc365535d5c4f97 upstream.

In older versions of the elantech hardware/firmware those bits always
were unset, so it didn't actually matter, but newer versions seem to
use those high bits for something else, screwing up the coordinates
we report to the input layer for those devices.

Signed-off-by: Florian Ragwitz 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: elantech - allow forcing Elantech protocol

2011-05-09T22:55:06+00:00

commit f81bc788ff91d4efd4baf88b2c29713838caa8e5 upstream.

Apparently hardware vendors now ship elantech touchpads with different version
magic. This options allows for them to be tested easier with the current driver
in order to add their magic to the whitelist later.

Signed-off-by: Florian Ragwitz 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: elantech - fix firmware version check

2011-05-09T22:55:05+00:00

commit 225c61aad38b12924b3df5f4ef43150c0d6bae8c upstream.

The check determining whether device should use 4- or 6-byte packets
was trying to compare firmware with 2.48, but was failing on majors
greater than 2. The new check ensures that versions like 4.1 are
checked properly.

Signed-off-by: Florian Ragwitz 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: elantech - do not advertise relative events

2011-05-09T22:55:05+00:00

commit c7a1f3ccfc2f99427f2e1545b3171e98539c3c95 upstream.

Elantech touchpads work in absolute mode and do not generate relative
events so they should not be advertising them.

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: Add support of Synaptics Clickpad device

2011-05-09T22:55:04+00:00

commit 5f57d67da87332a9a1ba8fa7a33bf0680e1c76e7 upstream.

The new type of touchpads can be detected via a new query command
0x0c. The clickpad flags are in cap[0]:4 and cap[1]:0 bits.

When the device is detected, the driver now reports only the left
button as the supported buttons so that X11 driver can detect that
the device is Clickpad. A Clickpad device gives the button events
only as the middle button. The kernel driver morphs to the left
button. The real handling of Clickpad is done rather in X driver
side.

Signed-off-by: Takashi Iwai 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: xen-kbdfront - fix mouse getting stuck after save/restore

2011-05-09T22:54:55+00:00

commit c36b58e8a9112017c2bcc322cc98e71241814303 upstream.

Mouse gets "stuck" after restore of PV guest but buttons are in working
condition.

If driver has been configured for ABS coordinates at start it will get
XENKBD_TYPE_POS events and then suddenly after restore it'll start getting
XENKBD_TYPE_MOTION events, that will be dropped later and they won't get
into user-space.

Regression was introduced by hunk 5 and 6 of
5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db
("Input: xen-kbdfront - advertise either absolute or relative
coordinates").

Driver on restore should ask xen for request-abs-pointer again if it is
available. So restore parts that did it before 5ea5254.

Acked-by: Olaf Hering 
Signed-off-by: Igor Mammedov 
[v1: Expanded the commit description]
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Dmitry Torokhov