<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/input, branch v3.12.19</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/input?h=v3.12.19</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/input?h=v3.12.19'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-04-03T08:32:25Z</updated>
<entry>
<title>Input: cypress_ps2 - don't report as a button pads</title>
<updated>2014-04-03T08:32:25Z</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2014-03-26T20:30:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6ed1a01c0d5512d66c04326cd4963ee1d871fa9c'/>
<id>urn:sha1:6ed1a01c0d5512d66c04326cd4963ee1d871fa9c</id>
<content type='text'>
commit 6797b39e6f6f34c74177736e146406e894b9482b upstream.

The cypress PS/2 trackpad models supported by the cypress_ps2 driver
emulate BTN_RIGHT events in firmware based on the finger position, as part
of this no motion events are sent when the finger is in the button area.

The INPUT_PROP_BUTTONPAD property is there to indicate to userspace that
BTN_RIGHT events should be emulated in userspace, which is not necessary
in this case.

When INPUT_PROP_BUTTONPAD is advertised userspace will wait for a motion
event before propagating the button event higher up the stack, as it needs
current abs x + y data for its BTN_RIGHT emulation. Since in the
cypress_ps2 pads don't report motion events in the button area, this means
that clicks in the button area end up being ignored, so
INPUT_PROP_BUTTONPAD actually causes problems for these touchpads, and
removing it fixes:

https://bugs.freedesktop.org/show_bug.cgi?id=76341

Reported-by: Adam Williamson &lt;awilliam@redhat.com&gt;
Tested-by: Adam Williamson &lt;awilliam@redhat.com&gt;
Reviewed-by: Peter Hutterer &lt;peter.hutterer@who-t.net&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Input: synaptics - add manual min/max quirk for ThinkPad X240</title>
<updated>2014-04-03T08:32:24Z</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2014-03-28T08:01:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=45b50b25b36538728f55f0a930b312af7fbb6e6f'/>
<id>urn:sha1:45b50b25b36538728f55f0a930b312af7fbb6e6f</id>
<content type='text'>
commit 8a0435d958fb36d93b8df610124a0e91e5675c82 upstream.

This extends Benjamin Tissoires manual min/max quirk table with support for
the ThinkPad X240.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Input: synaptics - add manual min/max quirk</title>
<updated>2014-04-03T08:32:24Z</updated>
<author>
<name>Benjamin Tissoires</name>
<email>benjamin.tissoires@redhat.com</email>
</author>
<published>2014-03-28T07:43:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0247679c66e193b785e7f1ac9c363612279c214f'/>
<id>urn:sha1:0247679c66e193b785e7f1ac9c363612279c214f</id>
<content type='text'>
commit 421e08c41fda1f0c2ff6af81a67b491389b653a5 upstream.

The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad.
However, these new Synaptics devices report bad axis ranges.
Under Windows, it is not a problem because the Windows driver uses RMI4
over SMBus to talk to the device. Under Linux, we are using the PS/2
fallback interface and it occurs the reported ranges are wrong.

Of course, it would be too easy to have only one range for the whole
series, each touchpad seems to be calibrated in a different way.

We can not use SMBus to get the actual range because I suspect the firmware
will switch into the SMBus mode and stop talking through PS/2 (this is the
case for hybrid HID over I2C / PS/2 Synaptics touchpads).

So as a temporary solution (until RMI4 land into upstream), start a new
list of quirks with the min/max manually set.

Signed-off-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Input: mousedev - fix race when creating mixed device</title>
<updated>2014-04-03T08:32:23Z</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2014-03-06T20:57:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3e477ed8dc6eb0415e9118d691688664080029ed'/>
<id>urn:sha1:3e477ed8dc6eb0415e9118d691688664080029ed</id>
<content type='text'>
commit e4dbedc7eac7da9db363a36f2bd4366962eeefcc upstream.

We should not be using static variable mousedev_mix in methods that can be
called before that singleton gets assigned. While at it let's add open and
close methods to mousedev structure so that we do not need to test if we
are dealing with multiplexor or normal device and simply call appropriate
method directly.

This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=71551

Reported-by: GiulioDP &lt;depasquale.giulio@gmail.com&gt;
Tested-by: GiulioDP &lt;depasquale.giulio@gmail.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Input: wacom - add support for three new Intuos Pro devices</title>
<updated>2014-04-03T08:32:21Z</updated>
<author>
<name>Ping Cheng</name>
<email>pinglinux@gmail.com</email>
</author>
<published>2014-03-27T22:40:02Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1c1fa991d7937e90eae0b15ade01632732ef3712'/>
<id>urn:sha1:1c1fa991d7937e90eae0b15ade01632732ef3712</id>
<content type='text'>
commit b5fd2a3e92ca5c8c1f3c20d31ac5daed3ec4d604 upstream.

Two tablets in this series support both pen and touch. One (Intuos S)
only supports pen. This patch also updates the driver to process wireless
devices that do not support touch interface.

Tested-by: Jason Gerecke &lt;killertofu@gmail.com&gt;
Acked-by: Chris Bagwell &lt;chris@cnpbagwell.com&gt;
Signed-off-by: Ping Cheng &lt;pingc@wacom.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Input: wacom - make sure touch_max is set for touch devices</title>
<updated>2014-03-31T12:22:34Z</updated>
<author>
<name>Ping Cheng</name>
<email>pinglinux@gmail.com</email>
</author>
<published>2013-11-26T02:43:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=16cf0c328d308b4bfb2baf0257bfdff47899a6ca'/>
<id>urn:sha1:16cf0c328d308b4bfb2baf0257bfdff47899a6ca</id>
<content type='text'>
commit 1d0d6df02750b4a6f466768cbfbf860e24f4c8d4 upstream.

Old single touch Tablet PCs do not have touch_max set at
wacom_features. Since touch device at lease supports one
finger, assign touch_max to 1 when touch usage is defined
in its HID Descriptor and touch_max is not pre-defined.

Tested-by: Jason Gerecke &lt;killertofu@gmail.com&gt;
Signed-off-by: Ping Cheng &lt;pingc@wacom.com&gt;
Reviewed-by: Chris Bagwell &lt;chris@cnpbagwell.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Cc: Josh Boyer &lt;jwboyer@fedoraproject.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Input: elantech - improve clickpad detection</title>
<updated>2014-03-31T12:22:32Z</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2013-12-16T15:09:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1743fc6cc6a54a4fac440ce885752cee819ed25a'/>
<id>urn:sha1:1743fc6cc6a54a4fac440ce885752cee819ed25a</id>
<content type='text'>
commit c15bdfd5b9831e4cab8cfc118243956e267dd30e upstream.

The current assumption in the elantech driver that hw version 3 touchpads
are never clickpads and hw version 4 touchpads are always clickpads is
wrong.

There are several bug reports for this, ie:
https://bugzilla.redhat.com/show_bug.cgi?id=1030802
http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux

I've spend a couple of hours wading through various bugzillas, launchpads
and forum posts to create a list of fw-versions and capabilities for
different laptop models to find a good method to differentiate between
clickpads and versions with separate hardware buttons.

Which shows that a device being a clickpad is reliable indicated by bit 12
being set in the fw_version. I've included the gathered list inside the
driver, so that we've this info at hand if we need to revisit this later.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Reviewed-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Cc: Josh Boyer &lt;jwboyer@fedoraproject.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Input - arizona-haptics: Fix double lock of dapm_mutex</title>
<updated>2014-03-05T16:13:54Z</updated>
<author>
<name>Charles Keepax</name>
<email>ckeepax@opensource.wolfsonmicro.com</email>
</author>
<published>2014-02-18T15:22:12Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=29e63f5f124dec97ee372cbab05611494f413adc'/>
<id>urn:sha1:29e63f5f124dec97ee372cbab05611494f413adc</id>
<content type='text'>
commit c4204960e9d0ba99459dbf1db918f99a45e7a62a upstream.

snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take
it externally as well. This patch fixes this.

Signed-off-by: Charles Keepax &lt;ckeepax@opensource.wolfsonmicro.com&gt;
Signed-off-by: Mark Brown &lt;broonie@linaro.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
</entry>
<entry>
<title>xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).</title>
<updated>2014-02-13T21:50:10Z</updated>
<author>
<name>Konrad Rzeszutek Wilk</name>
<email>konrad.wilk@oracle.com</email>
</author>
<published>2013-11-26T20:05:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d7c80b2d79624efd8fb6c2bfb44bd41ea2831cd4'/>
<id>urn:sha1:d7c80b2d79624efd8fb6c2bfb44bd41ea2831cd4</id>
<content type='text'>
commit 51c71a3bbaca868043cc45b3ad3786dd48a90235 upstream.

The user has the option of disabling the platform driver:
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)

which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
and allow the PV drivers to take over. If the user wishes
to disable that they can set:

  xen_platform_pci=0
  (in the guest config file)

or
  xen_emul_unplug=never
  (on the Linux command line)

except it does not work properly. The PV drivers still try to
load and since the Xen platform driver is not run - and it
has not initialized the grant tables, most of the PV drivers
stumble upon:

input: Xen Virtual Keyboard as /devices/virtual/input/input5
input: Xen Virtual Pointer as /devices/virtual/input/input6M
------------[ cut here ]------------
kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
invalid opcode: 0000 [#1] SMP
Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
RIP: 0010:[&lt;ffffffff813ddc40&gt;]  [&lt;ffffffff813ddc40&gt;] get_free_entries+0x2e0/0x300
Call Trace:
 [&lt;ffffffff8150d9a3&gt;] ? evdev_connect+0x1e3/0x240
 [&lt;ffffffff813ddd0e&gt;] gnttab_grant_foreign_access+0x2e/0x70
 [&lt;ffffffffa0010081&gt;] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
 [&lt;ffffffffa0010a12&gt;] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
 [&lt;ffffffff813e5757&gt;] xenbus_dev_probe+0x77/0x130
 [&lt;ffffffff813e7217&gt;] xenbus_frontend_dev_probe+0x47/0x50
 [&lt;ffffffff8145e9a9&gt;] driver_probe_device+0x89/0x230
 [&lt;ffffffff8145ebeb&gt;] __driver_attach+0x9b/0xa0
 [&lt;ffffffff8145eb50&gt;] ? driver_probe_device+0x230/0x230
 [&lt;ffffffff8145eb50&gt;] ? driver_probe_device+0x230/0x230
 [&lt;ffffffff8145cf1c&gt;] bus_for_each_dev+0x8c/0xb0
 [&lt;ffffffff8145e7d9&gt;] driver_attach+0x19/0x20
 [&lt;ffffffff8145e260&gt;] bus_add_driver+0x1a0/0x220
 [&lt;ffffffff8145f1ff&gt;] driver_register+0x5f/0xf0
 [&lt;ffffffff813e55c5&gt;] xenbus_register_driver_common+0x15/0x20
 [&lt;ffffffff813e76b3&gt;] xenbus_register_frontend+0x23/0x40
 [&lt;ffffffffa0015000&gt;] ? 0xffffffffa0014fff
 [&lt;ffffffffa001502b&gt;] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
 [&lt;ffffffff81002049&gt;] do_one_initcall+0x49/0x170

.. snip..

which is hardly nice. This patch fixes this by having each
PV driver check for:
 - if running in PV, then it is fine to execute (as that is their
   native environment).
 - if running in HVM, check if user wanted 'xen_emul_unplug=never',
   in which case bail out and don't load any PV drivers.
 - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
   does not exist, then bail out and not load PV drivers.
 - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
   then bail out for all PV devices _except_ the block one.
   Ditto for the network one ('nics').
 - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
   then load block PV driver, and also setup the legacy IDE paths.
   In (v3) make it actually load PV drivers.

Reported-by: Sander Eikelenboom &lt;linux@eikelenboom.it
Reported-by: Anthony PERARD &lt;anthony.perard@citrix.com&gt;
Reported-and-Tested-by: Fabio Fantoni &lt;fabio.fantoni@m2r.biz&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[v2: Add extra logic to handle the myrid ways 'xen_emul_unplug'
can be used per Ian and Stefano suggestion]
[v3: Make the unnecessary case work properly]
[v4: s/disks/ide-disks/ spotted by Fabio]
Reviewed-by: Stefano Stabellini &lt;stefano.stabellini@eu.citrix.com&gt;
Acked-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt; [for PCI parts]
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Input: allocate absinfo data when setting ABS capability</title>
<updated>2014-01-09T20:25:14Z</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2013-12-27T01:44:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=26021cf9139755640ddcd97bb286e5f5ee8efacf'/>
<id>urn:sha1:26021cf9139755640ddcd97bb286e5f5ee8efacf</id>
<content type='text'>
commit 28a2a2e1aedbe2d8b2301e6e0e4e63f6e4177aca upstream.

We need to make sure we allocate absinfo data when we are setting one of
EV_ABS/ABS_XXX capabilities, otherwise we may bomb when we try to emit this
event.

Rested-by: Paul Cercueil &lt;pcercuei@gmail.com&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
