linux/drivers/input/mouse/synaptics.c, branch v3.8

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

2012-10-03T00:16:10Z

Pull input updates from Dmitry Torokhov: "A few drivers were updated with device tree bindings and others got a few small cleanups and fixes." Fix trivial conflict in drivers/input/keyboard/omap-keypad.c due to changes clashing with a whitespace cleanup. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (28 commits) Input: wacom - mark Intuos5 pad as in-prox when touching buttons Input: synaptics - adjust threshold for treating position values as negative Input: hgpk - use %*ph to dump small buffer Input: gpio_keys_polled - fix dt pdata->nbuttons Input: Add KD[GS]KBDIACRUC ioctls to the compatible list Input: omap-keypad - fixed formatting Input: tegra - move platform data header Input: wacom - add support for EMR on Cintiq 24HD touch Input: s3c2410_ts - make s3c_ts_pmops const Input: samsung-keypad - use of_get_child_count() helper Input: samsung-keypad - use of_match_ptr() Input: uinput - fix formatting Input: uinput - specify exact bit sizes on userspace APIs Input: uinput - mark failed submission requests as free Input: uinput - fix race that can block nonblocking read Input: uinput - return -EINVAL when read buffer size is too small Input: uinput - take event lock when fetching events from buffer Input: get rid of MATCH_BIT() macro Input: rotary-encoder - add DT bindings Input: rotary-encoder - constify platform data pointers ...

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

2012-09-28T17:33:57Z

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 Cc: stable@vger.kernel.org Signed-off-by: Seth Forshee Reviewed-by: Daniel Kurtz Tested-by: Alan Swanson Tested-by: Arteom Signed-off-by: Dmitry Torokhov

Input: MT - Add flags to input_mt_init_slots()

2012-09-19T17:50:18Z

Preparing to move more repeated code into the mt core, add a flags argument to the input_mt_slots_init() function. Reviewed-and-tested-by: Benjamin Tissoires Tested-by: Ping Cheng Acked-by: Dmitry Torokhov Signed-off-by: Henrik Rydberg

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

2012-07-25T06:55:15Z

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 Cc: stable@vger.kernel.org Signed-off-by: Seth Forshee Reviewed-by: Daniel Kurtz Signed-off-by: Dmitry Torokhov

Input: synaptics - print firmware ID and board number at init

2012-07-08T01:20:08Z

Read the Firmware ID and Board Number from a synaptics device at init and display them in the system log. Device behavior is very board and firmware dependent. It may prove useful for users to include this information when providing bug reports or other feedback. Signed-off-by: Daniel Kurtz Acked-by: Henrik Rydberg Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2012-05-24T08:13:01Z

Input: synaptics - fix compile warning

2012-05-11T05:33:49Z

Move synaptics_invert_y() inside CONFIG_MOUSE_PS2_SYNAPTICS to get rid of a compile warning when we don't select synaptics support. drivers/input/mouse/synaptics.c:53:12: warning: ‘synaptics_invert_y’ defined but not used [-Wunused-function] Signed-off-by: JJ Ding Reviewed-by: Daniel Kurtz Signed-off-by: Dmitry Torokhov

Input: synaptics - fix regression with "image sensor" trackpads

2012-04-21T05:47:28Z

commit 7968a5dd492ccc38345013e534ad4c8d6eb60ed1 Input: synaptics - add support for Relative mode Accidentally broke support for advanced gestures (multitouch) on some trackpads such as the one in my ThinkPad X220 by incorretly changing the condition for enabling them. This restores it. Signed-off-by: Benjamin Herrenschmidt CC: stable@kernel.org [3.3] Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2012-01-09T07:38:23Z

Input: synaptics - fix touchpad not working after S2R on Vostro V13

2011-12-12T08:06:56Z

Synaptics touchpads on several Dell laptops, particularly Vostro V13 systems, may not respond properly to PS/2 commands and queries immediately after resuming from suspend to RAM. This leads to unresponsive touchpad after suspend/resume cycle. Adding a 1-second delay after resetting the device allows touchpad to finish initializing (calibrating?) and start reacting properly. Reported-by: Daniel Manrique Tested-by: Daniel Manrique Cc: stable@kernel.org Signed-off-by: Dmitry Torokhov