linux/drivers/input, branch v4.1

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

2015-06-09T22:05:27Z

Pull input layer fix from Dmitry Torokhov: "A small tweak for the Synaptics PS/2 touchpad driver" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: synaptics - add min/max quirk for Lenovo S540

Input: synaptics - add min/max quirk for Lenovo S540

2015-06-08T17:19:08Z

https://bugzilla.redhat.com/show_bug.cgi?id=1223051#c2 Cc: stable@vger.kernel.org Tested-by: tommy.gagnes@gmail.com Signed-off-by: Peter Hutterer Signed-off-by: Dmitry Torokhov

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

2015-06-06T16:08:23Z

Pull input subsystem fixes from Dmitry Torokhov: "Just a couple touchpad drivers fixups" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: alps - do not reduce trackpoint speed by half Input: elantech - add new icbody type Input: elantech - fix detection of touchpads where the revision matches a known rate

Input: alps - do not reduce trackpoint speed by half

2015-06-05T05:34:40Z

On some v7 devices (e.g. Lenovo-E550) the deltas reported are typically only in the 0-1 range dividing this by 2 results in a range of 0-0. And even for v7 devices where this does not lead to making the trackstick entirely unusable, it makes it twice as slow as before we added v7 support and were using the ps/2 mouse emulation of the dual point setup. If some kind of generic slowdown is actually necessary for some devices, then that belongs in userspace, not in the kernel. Cc: stable@vger.kernel.org Reported-and-tested-by: Rico Moorman Signed-off-by: Hans de Goede Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov

Input: elantech - add new icbody type

2015-06-05T05:34:39Z

This adds new icbody type to the list recognized by Elantech PS/2 driver. Cc: stable@vger.kernel.org Signed-off-by: Sam Hung Signed-off-by: Dmitry Torokhov

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

2015-06-02T17:43:07Z

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. Cc: stable@vger.kernel.org Reported-and-tested-by: David Zafra Gómez Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

2015-05-22T21:49:55Z

Pull input fixes from Dmitry Torokhov: "Updates for the input subsystem. The main change is that we tell joydev not to touch "absolute mice", such as VMware virtual mouse, as that produced bad result (cursor stuck in upper right corner) with games" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: smtpe-ts - wait 50mS until polling for pen-up Input: smtpe-ts - use msecs_to_jiffies() instead of HZ Input: joydev - don't classify the vmmouse as a joystick Input: vmmouse - do not reference non-existing version of X driver Input: alps - fix finger jumps on lifting 2 fingers on v7 touchpad Input: elantech - fix semi-mt protocol for v3 HW Input: sx8654 - fix memory allocation check

Input: smtpe-ts - wait 50mS until polling for pen-up

2015-05-22T00:06:13Z

Wait a little bit longer, 50mS instead of 20mS, until the driver starts polling for pen-up. The problematic behavior before this patch is applied is as follows. The behavior was observed on the STMPE610QTR controller. Upon a physical pen-down event, the touchscreen reports one set of x-y-p coordinates and a pen-down event. After that, the pen-up polling is triggered and since the controller is not ready yet, the polling mistakenly detects a pen-up event while the physical state is still such that the pen is down on the touch surface. The pen-up handling flushes the controller FIFO, so after that, all the samples in the controller are discarded. The controller becomes ready shortly after this bogus pen-up handling and does generate again a pen-down interrupt. This time, the controller contains x-y-p samples which all read as zero. Since pressure value is zero, this set of samples is effectively ignored by userland. In the end, the driver just bounces between pen-down and bogus pen-up handling, generating no useful results. Fix this by giving the controller a bit more time before polling it for pen-up. Signed-off-by: Marek Vasut Reviewed-by: Viresh Kumar Signed-off-by: Dmitry Torokhov

Input: smtpe-ts - use msecs_to_jiffies() instead of HZ

2015-05-22T00:05:48Z

Use msecs_to_jiffies(20) instead of plain (HZ / 50), as the former is much more explicit about it's behavior. We want to schedule the task 20 mS from now, so make it explicit in the code. Signed-off-by: Marek Vasut Reviewed-by: Viresh Kumar Signed-off-by: Dmitry Torokhov

Input: joydev - don't classify the vmmouse as a joystick

2015-05-21T22:58:27Z

Joydev is currently thinking some absolute mice are joystick, and that messes up games in VMware guests, as the cursor typically gets stuck in the top left corner. Try to detect the event signature of a VMmouse input device and back off for such devices. We're still incorrectly detecting, for example, the VMware absolute USB mouse as a joystick, but adding an event signature matching also that device would be considerably more risky, so defer that to a later merge window. Signed-off-by: Thomas Hellstrom Signed-off-by: Dmitry Torokhov