<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/input, branch v3.18</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v3.18</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v3.18'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2014-12-03T17:35:38Z</updated>
<entry>
<title>drivers/input/evdev.c: don't kfree() a vmalloc address</title>
<updated>2014-12-03T17:35:38Z</updated>
<author>
<name>Andrew Morton</name>
<email>akpm@linux-foundation.org</email>
</author>
<published>2014-12-02T23:59:31Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=92788ac1eb06e69a822de45e2a8a63fa45eb5be2'/>
<id>urn:sha1:92788ac1eb06e69a822de45e2a8a63fa45eb5be2</id>
<content type='text'>
If kzalloc() failed and then evdev_open_device() fails, evdev_open()
will pass a vmalloc'ed pointer to kfree.

This might fix https://bugzilla.kernel.org/show_bug.cgi?id=88401, where
there was a crash in kfree().

Reported-by: Christian Casteyde &lt;casteyde.christian@free.fr&gt;
Belatedly-Acked-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Cc: Henrik Rydberg &lt;rydberg@euromail.se&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input</title>
<updated>2014-11-28T01:51:50Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-11-28T01:51:50Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=0210bb6083e655981ebe9ea2fc6a4ab4e96d4bff'/>
<id>urn:sha1:0210bb6083e655981ebe9ea2fc6a4ab4e96d4bff</id>
<content type='text'>
Pull input layer fixes from Dmitry Torokhov:
 "The main change is to fix breakage in Elantech driver introduced by
  the recent commit adding trackpoint reporting to protocol v4.  Now we
  are trusting the hardware to advertise the trackpoint properly and do
  not try to decode the data as trackpoint if firmware told us it is not
  present"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: xpad - use proper endpoint type
  Input: elantech - trust firmware about trackpoint presence
  Input: synaptics - adjust min/max on Thinkpad E540
</content>
</entry>
<entry>
<title>Input: xpad - use proper endpoint type</title>
<updated>2014-11-25T08:42:19Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2014-11-25T08:38:17Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a1f9a4072655843fc03186acbad65990cc05dd2d'/>
<id>urn:sha1:a1f9a4072655843fc03186acbad65990cc05dd2d</id>
<content type='text'>
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" &lt;pgriffais@valvesoftware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
<entry>
<title>Input: elantech - trust firmware about trackpoint presence</title>
<updated>2014-11-25T08:42:13Z</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2014-11-20T07:33:07Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d0ab54783f2de0c216115333eca1a8d3d5c3e75b'/>
<id>urn:sha1:d0ab54783f2de0c216115333eca1a8d3d5c3e75b</id>
<content type='text'>
Only try to parse data as coming from trackpoint if firmware told us that
trackpoint is present.

Fixes commit caeb0d37fa3e387eb0dd22e5d497523c002033d1

Reported-and-tested-by: Marcus Overhagen &lt;marcus.overhagen@gmail.com&gt;
Reported-and-tested-by: Anders Kaseorg &lt;andersk@mit.edu&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
<entry>
<title>Input: synaptics - adjust min/max on Thinkpad E540</title>
<updated>2014-11-17T02:22:38Z</updated>
<author>
<name>Ben Sagal</name>
<email>bensagal@gmail.com</email>
</author>
<published>2014-11-17T01:23:40Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=bce4f9e764c36bc35dd5c9cf9e057c09f422397d'/>
<id>urn:sha1:bce4f9e764c36bc35dd5c9cf9e057c09f422397d</id>
<content type='text'>
The LEN2006 Synaptics touchpad (as found in Thinkpad E540) returns wrong
min max values.

touchpad-edge-detector output:
&gt;  Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event6
&gt;  Move one finger around the touchpad to detect the actual edges
&gt;  Kernel says:    x [1472..5674], y [1408..4684]
&gt;  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 &lt;bensagal@gmail.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input</title>
<updated>2014-11-14T22:31:54Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-11-14T22:31:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=56c381f93d57b88a3e667a2f55137947315c17e2'/>
<id>urn:sha1:56c381f93d57b88a3e667a2f55137947315c17e2</id>
<content type='text'>
Pull input subsystem updates from Dmitry Torokhov:
 "Mostly small fixups to PS/2 tochpad drivers (ALPS, Elantech,
  Synaptics) to better deal with specific hardware"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: elantech - update the documentation
  Input: elantech - provide a sysfs knob for crc_enabled
  Input: elantech - report the middle button of the touchpad
  Input: alps - ignore bad data on Dell Latitudes E6440 and E7440
  Input: alps - allow up to 2 invalid packets without resetting device
  Input: alps - ignore potential bare packets when device is out of sync
  Input: elantech - fix crc_enabled for Fujitsu H730
  Input: elantech - use elantech_report_trackpoint for hardware v4 too
  Input: twl4030-pwrbutton - ensure a wakeup event is recorded.
  Input: synaptics - add min/max quirk for Lenovo T440s
</content>
</entry>
<entry>
<title>Input: elantech - provide a sysfs knob for crc_enabled</title>
<updated>2014-11-14T01:50:23Z</updated>
<author>
<name>Ulrik De Bie</name>
<email>ulrik.debie-os@e2big.org</email>
</author>
<published>2014-11-14T01:47:04Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2d9eb81fdb9f08df3a4b1638c1270a4453b40ac2'/>
<id>urn:sha1:2d9eb81fdb9f08df3a4b1638c1270a4453b40ac2</id>
<content type='text'>
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 &lt;stefan@valouch.com&gt;
Signed-off-by: Ulrik De Bie &lt;ulrik.debie-os@e2big.org&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
<entry>
<title>Input: elantech - report the middle button of the touchpad</title>
<updated>2014-11-14T01:50:22Z</updated>
<author>
<name>Ulrik De Bie</name>
<email>ulrik.debie-os@e2big.org</email>
</author>
<published>2014-11-14T01:45:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f386474e12a560e005ec7899e78f51f6bdc3cf41'/>
<id>urn:sha1:f386474e12a560e005ec7899e78f51f6bdc3cf41</id>
<content type='text'>
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 &lt;stefan@valouch.com&gt;
Signed-off-by: Ulrik De Bie &lt;ulrik.debie-os@e2big.org&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
<entry>
<title>Input: alps - ignore bad data on Dell Latitudes E6440 and E7440</title>
<updated>2014-11-14T01:42:57Z</updated>
<author>
<name>Pali Rohár</name>
<email>pali.rohar@gmail.com</email>
</author>
<published>2014-11-09T07:36:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a7ef82aee91f26da79b981b9f5bca43b8817d3e4'/>
<id>urn:sha1:a7ef82aee91f26da79b981b9f5bca43b8817d3e4</id>
<content type='text'>
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 &lt;pali.rohar@gmail.com&gt;
Tested-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
<entry>
<title>Input: alps - allow up to 2 invalid packets without resetting device</title>
<updated>2014-11-10T06:58:38Z</updated>
<author>
<name>Pali Rohár</name>
<email>pali.rohar@gmail.com</email>
</author>
<published>2014-11-08T20:58:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9d720b34c0a432639252f63012e18b0507f5b432'/>
<id>urn:sha1:9d720b34c0a432639252f63012e18b0507f5b432</id>
<content type='text'>
On some Dell Latitude laptops ALPS device or Dell EC send one invalid byte
in 6 bytes ALPS packet. In this case psmouse driver enter out of sync
state. It looks like that all other bytes in packets are valid and also
device working properly. So there is no need to do full device reset, just
need to wait for byte which match condition for first byte (start of
packet). Because ALPS packets are bigger (6 or 8 bytes) default limit is
small.

This patch increase number of invalid bytes to size of 2 ALPS packets which
psmouse driver can drop before do full reset.

Resetting ALPS devices take some time and when doing reset on some Dell
laptops touchpad, trackstick and also keyboard do not respond. So it is
better to do it only if really necessary.

Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Tested-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
</content>
</entry>
</feed>
