linux/drivers/input, branch v3.2.38

Input: walkera0701 - fix crash on startup

2013-01-03T03:33:42Z

commit a455e2985f57e2a71566bb8850094af38b2c932d upstream. The driver's timer must be set up before enabling IRQ handler, otherwise bad things may happen. Reported-and-tested-by: Fengguang Wu Signed-off-by: Peter Popovec Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

x86, 8042: Enable A20 using KBC to fix S3 resume on some MSI laptops

2013-01-03T03:33:36Z

commit ad68652412276f68ad4fe3e1ecf5ee6880876783 upstream. Some MSI laptop BIOSes are broken - INT 15h code uses port 92h to enable A20 line but resume code assumes that KBC was used. The laptop will not resume from S3 otherwise but powers off after a while and then powers on again stuck with a blank screen. Fix it by enabling A20 using KBC in i8042_platform_init for x86. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=12878 Signed-off-by: Ondrej Zary Cc: Dmitry Torokhov Cc: Alan Cox Cc: Rafael J. Wysocki Link: http://lkml.kernel.org/r/201212112218.06551.linux@rainbow-software.org Signed-off-by: H. Peter Anvin Signed-off-by: Ben Hutchings

Input: bcm5974 - set BUTTONPAD property

2012-12-06T11:20:20Z

commit 52965cc012f7a3cf35f06485ec275ebf3b3fddae upstream. Some bcm5974 trackpads have a physical button beneath the physical surface. This patch sets the property bit so user space applications can detect the trackpad type and act accordingly. Signed-off-by: Jussi Pakkanen Reviewed-by: Henrik Rydberg Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

Input: i8042 - also perform controller reset when suspending

2012-12-06T11:20:13Z

commit 1729ad1f4f9e167ade84ca8b5269695c42351160 upstream. In addition to some laptops needing i8042 reset after resuming from S2R to get their touchpads working there is another class of laptops - ones that need i8042 reset before going to S2R, otherwise they will simply reboot instead of resuming. See https://bugzilla.kernel.org/show_bug.cgi?id=15612 This change forces reset of i8042 before doing S2R. Reported-by: Stefan Koch Tested-by: Alexander van Loon Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

Input: tsc40 - remove wrong announcement of pressure support

2012-11-16T16:47:02Z

commit 32ed1911fc79908d704023317d4ddeb3883fd07e upstream. The tsc40 driver announces it supports the pressure event, but will never send one. The announcement will cause tslib to wait for such events and sending all touch events with a pressure of 0. Removing the announcement will make tslib fall back to emulating the pressure on touch events so everything works as expected. Signed-off-by: Rolf Eike Beer Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

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

2012-10-17T02:49:11Z

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

Input: i8042 - disable mux on Toshiba C850D

2012-10-10T02:31:00Z

commit 8669cf6793bb38307a30fb6b9565ddc8840ebd3f upstream. On Toshiba Satellite C850D, the touchpad and the keyboard might randomly not work at boot. Preventing MUX mode activation solves this issue. Signed-off-by: Anisse Astier Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

Input: i8042 - add Gigabyte T1005 series netbooks to noloop table

2012-09-19T14:04:27Z

commit 7b125b94ca16b7e618c6241cb02c4c8060cea5e3 upstream. They all define their chassis type as "Other" and therefore are not categorized as "laptops" by the driver, which tries to perform AUX IRQ delivery test which fails and causes touchpad not working. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42620 Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings

Input: eeti_ts: pass gpio value instead of IRQ

2012-08-19T17:15:34Z

commit 4eef6cbfcc03b294d9d334368a851b35b496ce53 upstream. The EETI touchscreen asserts its IRQ line as soon as it has data in its internal buffers. The line is automatically deasserted once all data has been read via I2C. Hence, the driver has to monitor the GPIO line and cannot simply rely on the interrupt handler reception. In the current implementation of the driver, irq_to_gpio() is used to determine the GPIO number from the i2c_client's IRQ value. As irq_to_gpio() is not available on all platforms, this patch changes this and makes the driver ignore the passed in IRQ. Instead, a GPIO is added to the platform_data struct and gpio_to_irq is used to derive the IRQ from that GPIO. If this fails, bail out. The driver is only able to work in environments where the touchscreen GPIO can be mapped to an IRQ. Without this patch, building raumfeld_defconfig results in: drivers/input/touchscreen/eeti_ts.c: In function 'eeti_ts_irq_active': drivers/input/touchscreen/eeti_ts.c:65:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration] Signed-off-by: Daniel Mack Signed-off-by: Arnd Bergmann Cc: Dmitry Torokhov Cc: Sven Neumann Cc: linux-input@vger.kernel.org Cc: Haojian Zhuang [bwh: Backported to 3.2: raumfeld_controller_i2c_board_info.irq was initialised using gpio_to_irq(), but this doesn't seem to matter] Signed-off-by: Ben Hutchings

Input: synaptics - handle out of bounds values from the hardware

2012-08-09T23:24:51Z

commit c0394506e69b37c47d391c2a7bbea3ea236d8ec8 upstream. The touchpad on the Acer Aspire One D250 will report out of range values in the extreme lower portion of the touchpad. These appear as abrupt changes in the values reported by the hardware from very low values to very high values, which can cause unexpected vertical jumps in the position of the mouse pointer. What seems to be happening is that the value is wrapping to a two's compliment negative value of higher resolution than the 13-bit value reported by the hardware, with the high-order bits being truncated. This patch adds handling for these values by converting them to the appropriate negative values. The only tricky part about this is deciding when to treat a number as negative. It stands to reason that if out of range values can be reported on the low end then it could also happen on the high end, so not all out of range values should be treated as negative. The approach taken here is to split the difference between the maximum legitimate value for the axis and the maximum possible value that the hardware can report, treating values greater than this number as negative and all other values as positive. This can be tweaked later if hardware is found that operates outside of these parameters. BugLink: http://bugs.launchpad.net/bugs/1001251 Signed-off-by: Seth Forshee Reviewed-by: Daniel Kurtz Signed-off-by: Dmitry Torokhov [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings