linux-toradex.git/drivers/input, branch v2.6.32.58

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

Input: xen-kbdfront - advertise either absolute or relative coordinates

2011-03-27T18:30:49+00:00

commit 8c3c283e6bf463ab498d6e7823aff6c4762314b6 upstream.

A virtualized display device is usually viewed with the vncviewer
application, either by 'xm vnc domU' or with vncviewer localhost:port.
vncviewer and the RFB protocol provides absolute coordinates to the
virtual display. These coordinates are either passed through to a PV
guest or converted to relative coordinates for a HVM guest.

A PV guest receives these coordinates and passes them to the kernels
evdev driver. There it can be picked up by applications such as the
xorg-input drivers. Using absolute coordinates avoids issues such as
guest mouse pointer not tracking host mouse pointer due to wrong mouse
acceleration settings in the guests X display.

Advertise either absolute or relative coordinates to the input system
and the evdev driver, depending on what dom0 provides. The xorg-input
driver prefers relative coordinates even if a devices provides both.

Signed-off-by: Olaf Hering 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman