Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v3.5.3 2012-08-15T14:53:04+00:00 2012-08-15T14:53:04+00:00 Chris Bagwell chris@cnpbagwell.com 2012-06-12T07:25:48+00:00 urn:sha1:ec6942d015aab53df3a3b4aaf6755b4a039355a1 commit 6dc463511d4a690f01a9248df3b384db717e0b1c upstream. Bamboo One's with ID of 0x6a and 0x6b were added with correct indication of 1024 pressure levels but the Graphire packet routine was only looking at 9 bits. Increased to 10 bits. This bug caused these devices to roll over to zero pressure at half way mark. The other devices using this routine only support 256 or 512 range and look to fix unused bits at zero. Signed-off-by: Chris Bagwell <chris@cnpbagwell.com> Reported-by: Tushant Mirchandani <tushantin@gmail.com> Reviewed-by: Ping Cheng <pingc@wacom.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-08-15T14:53:04+00:00 Arnd Bergmann arnd@arndb.de 2012-04-30T16:21:37+00:00 urn:sha1:3aea730ce57eed9a71ae1aa3bfa65527fbf4192d 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 <zonque@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Sven Neumann <s.neumann@raumfeld.com> Cc: linux-input@vger.kernel.org Cc: Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-08-15T14:52:47+00:00 Seth Forshee seth.forshee@canonical.com 2012-07-25T06:54:11+00:00 urn:sha1:afcbdbdebc0a84e8a1495487e1736345122b3fba 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 <seth.forshee@canonical.com> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-07-13T17:33:18+00:00 Linus Torvalds torvalds@linux-foundation.org 2012-07-13T17:33:18+00:00 urn:sha1:39ea32ca7e425cde24df04f34bf76746ea028681 Pull input layer fixes from Dmitry Torokhov: "The changes are limited to adding new VID/PID combinations to drivers to enable support for new versions of hardware, most notably hardware found in new MacBook Pro Retina boxes." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: xpad - add Andamiro Pump It Up pad Input: xpad - add signature for Razer Onza Tournament Edition Input: xpad - handle all variations of Mad Catz Beat Pad Input: bcm5974 - Add support for 2012 MacBook Pro Retina HID: add support for 2012 MacBook Pro Retina 2012-07-13T06:59:39+00:00 Yuri Khan yurivkhan@gmail.com 2012-07-12T05:12:31+00:00 urn:sha1:e76b8ee25e034ab601b525abb95cea14aa167ed3 I couldn't find the vendor ID in any of the online databases, but this mat has a Pump It Up logo on the top side of the controller compartment, and a disclaimer stating that Andamiro will not be liable on the bottom. Signed-off-by: Yuri Khan <yurivkhan@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2012-07-11T07:55:06+00:00 Ilia Katsnelson k0009000@gmail.com 2012-07-11T07:54:20+00:00 urn:sha1:cc71a7e899cc6b2ff41e1be48756782ed004d802 Signed-off-by: Ilia Katsnelson <k0009000@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2012-07-11T07:54:49+00:00 Yuri Khan yurivkhan@gmail.com 2012-07-11T07:49:18+00:00 urn:sha1:3ffb62cb9ac2430c2504c6ff9727d0f2476ef0bd The device should be handled by xpad driver instead of generic HID driver. Signed-off-by: Yuri Khan <yurivkhan@gmail.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2012-07-10T16:45:05+00:00 Henrik Rydberg rydberg@euromail.se 2012-07-10T16:43:57+00:00 urn:sha1:3dde22a98e94eb18527f0ff0068fb2fb945e58d4 Add support for the 15'' MacBook Pro Retina model (MacBookPro10,1). Patch originally written by clipcarl (forums.opensuse.org). Signed-off-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2012-07-06T16:50:39+00:00 Linus Torvalds torvalds@linux-foundation.org 2012-07-06T16:50:39+00:00 urn:sha1:1b74a8684e3c5cbbe5e798de9e07e3a087c7b853 Pull input layer fixes from Dmitry Torokhov: "Two fixes for regressions in Wacom driver and fixes for drivers using threaded IRQ framework without specifying IRQF_ONESHOT." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: request threaded-only IRQs with IRQF_ONESHOT Input: wacom - don't retrieve touch_max when it is predefined Input: wacom - fix retrieving touch_max bug Input: fix input.h kernel-doc warning 2012-07-04T20:12:19+00:00 Lars-Peter Clausen lars@metafoo.de 2012-07-04T20:02:56+00:00 urn:sha1:9b7e31bbf4bb58b12e11a7f24b7c3e48bbd2f4da Since commit 1c6c69525b ("genirq: Reject bogus threaded irq requests") threaded IRQs without a primary handler need to be requested with IRQF_ONESHOT, otherwise the request will fail. This patch adds the IRQF_ONESHOT to input drivers where it is missing. Not modified by this patch are those drivers where the requested IRQ will always be a nested IRQ (e.g. because it's part of an MFD), since for this special case IRQF_ONESHOT is not required to be specified when requesting the IRQ. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>