kernel/linux.git/drivers/input, branch v3.4.105

Input: i8042 - add nomux quirk for Avatar AVIU-145A6

2014-12-01T10:02:33+00:00

commit d2682118f4bb3ceb835f91c1a694407a31bb7378 upstream. The sys_vendor / product_name are somewhat generic unfortunately, so this may lead to some false positives. But nomux usually does no harm, where as not having it clearly is causing problems on the Avatar AVIU-145A6. https://bugzilla.kernel.org/show_bug.cgi?id=77391 Reported-by: Hugo P Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li

Input: i8042 - add Fujitsu U574 to no_timeout dmi table

2014-12-01T10:02:33+00:00

commit cc18a69c92d0972bc2fc5a047ee3be1e8398171b upstream. https://bugzilla.kernel.org/show_bug.cgi?id=69731 Reported-by: Jason Robinson Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li

Input: serport - add compat handling for SPIOCSTYPE ioctl

2014-12-01T10:02:29+00:00

commit a80d8b02751060a178bb1f7a6b7a93645a7a308b upstream. When running a 32-bit inputattach utility in a 64-bit system, there will be error code "inputattach: can't set device type". This is caused by the serport device driver not supporting compat_ioctl, so that SPIOCSTYPE ioctl fails. Signed-off-by: John Sung Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li

Input: synaptics - add support for ForcePads

2014-12-01T10:02:28+00:00

commit 5715fc764f7753d464dbe094b5ef9cffa6e479a4 upstream. ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of physical buttons, instead they generate primary button click when user presses somewhat hard on the surface of the touchpad. Unfortunately they also report primary button click whenever there are 2 or more contacts on the pad, messing up all multi-finger gestures (2-finger scrolling, multi-finger tapping, etc). To cope with this behavior we introduce a delay (currently 50 msecs) in reporting primary press in case more contacts appear. Reviewed-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li

Input: elantech - fix detection of touchpad on ASUS s301l

2014-12-01T10:02:27+00:00

commit 271329b3c798b2102120f5df829071c211ef00ed upstream. Adjust Elantech signature validation to account fo rnewer models of touchpads. Reported-and-tested-by: Màrius Monton Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li

Input: elantech - deal with clickpads reporting right button events

2014-07-07T01:49:19+00:00

commit cd9e83e2754465856097f31c7ab933ce74c473f8 upstream. At least the Dell Vostro 5470 elantech *clickpad* reports right button clicks when clicked in the right bottom area: https://bugzilla.redhat.com/show_bug.cgi?id=1103528 This is different from how (elantech) clickpads normally operate, normally no matter where the user clicks on the pad the pad always reports a left button event, since there is only 1 hardware button beneath the path. It looks like Dell has put 2 buttons under the pad, one under each bottom corner, causing this. Since this however still clearly is a real clickpad hardware-wise, we still want to report it as such to userspace, so that things like finger movement in the bottom area can be properly ignored as it should be on clickpads. So deal with this weirdness by simply mapping a right click to a left click on elantech clickpads. As an added advantage this is something which we can simply do on all elantech clickpads, so no need to add special quirks for this weird model. Reported-and-tested-by: Elder Marco Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: synaptics - adjust threshold for treating position values as negative

2014-06-07T23:02:06+00:00

commit 824efd37415961d38821ecbd9694e213fb2e8b32 upstream. Commit c039450 (Input: synaptics - handle out of bounds values from the hardware) caused any hardware reported values over 7167 to be treated as a wrapped-around negative value. It turns out that some firmware uses the value 8176 to indicate a finger near the edge of the touchpad whose actual position cannot be determined. This value now gets treated as negative, which can cause pointer jumps and broken edge scrolling on these machines. I only know of one touchpad which reports negative values, and this hardware never reports any value lower than -8 (i.e. 8184). Moving the threshold for treating a value as negative up to 8176 should work fine then for any hardware we currently know about, and since we're dealing with unspecified behavior it's probably the best we can do. The special 8176 value is also likely to result in sudden jumps in position, so let's also clamp this to the maximum specified value for the axis. BugLink: http://bugs.launchpad.net/bugs/1046512 https://bugzilla.kernel.org/show_bug.cgi?id=46371 Signed-off-by: Seth Forshee Reviewed-by: Daniel Kurtz Tested-by: Alan Swanson Tested-by: Arteom Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings Cc: Qiang Huang Signed-off-by: Greg Kroah-Hartman

Input: synaptics - add manual min/max quirk for ThinkPad X240

2014-04-03T18:58:46+00:00

commit 8a0435d958fb36d93b8df610124a0e91e5675c82 upstream. This extends Benjamin Tissoires manual min/max quirk table with support for the ThinkPad X240. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: synaptics - add manual min/max quirk

2014-04-03T18:58:46+00:00

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 Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: elantech - improve clickpad detection

2014-03-31T04:40:30+00:00

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 Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Cc: Josh Boyer Signed-off-by: Greg Kroah-Hartman