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

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

Input: synaptics - update OLPC XO exclusion

2011-11-15T17:46:29Z

We have determined that the jumpiness previously seen when using the synaptics kernel mouse driver on OLPC XO was due to not using the synaptics X11 userspace driver - the xf86-input-evdev driver was interpreting 'finger near pad' signals as movements. Newer versions of xf86-input-evdev fix this issue. Additionally, the synaptics kernel driver is now usable on this platform, but only when run in relative mode. Update the comment and refine the check to allow the synaptics driver to run on OLPC XO in relative mode. We will continue investigating the EC issue as time becomes available. Signed-off-by: Daniel Drake Signed-off-by: Dmitry Torokhov

Input: synaptics - add support for Relative mode

2011-11-10T05:23:31Z

Currently, the synaptics driver puts the device into Absolute mode. As explained in the synaptics documentation section 3.2, in this mode, the device sends a continuous stream of packets at the maximum rate to the host when the user's fingers are near or on the pad or pressing buttons, and continues streaming for 1 second afterwards. These packets are even sent when there is no new information to report, even when they are duplicates of the previous packet. For embedded systems this is a bit much - it results in a huge and uninterrupted stream of interrupts at high rate. This patch adds support for Relative mode, which can be selected as a new psmouse protocol. In this mode, the device does not send duplicate packets and acts like a standard PS/2 mouse. However, synaptics-specific functionality is still available, such as the ability to set the packet rate, and rather than disabling gestures and taps at the hardware level unconditionally, a 'synaptics_disable_gesture' sysfs attribute has been added to allow control of this functionality. This solves a long standing OLPC issue: synaptics hardware enables tap to click by default (even in the default relative mode), but we have found this to be inappropriate for young children and first time computer users. Enabling the synaptics driver disables tap-to-click, but we have previously been unable to use this because it also enables Absolute mode, which is too "spammy" for our desires and actually overloads our EC with its continuous stream of packets. Now we can enable the synaptics driver, disabling tap to click while retaining the less noisy Relative mode. Signed-off-by: Daniel Drake Signed-off-by: Dmitry Torokhov

Input: psmouse - switch to using dev_*() for messages

2011-10-11T01:28:16Z

This will ensure our reporting is consistent with the rest of the system and we do not refer to obsolete source file names. Reviewed-by: Wanlong Gao Reviewed-by: JJ Ding Reviewed-by: Daniel Kurtz Signed-off-by: Dmitry Torokhov

Input: synaptics - process finger (<=5) transitions

2011-08-24T06:08:32Z

Synaptics image sensor touchpads track up to 5 fingers, but only report 2. They use a special "TYPE=2" (AGM-CONTACT) packet type that reports the number of tracked fingers and which finger is reported in the SGM and AGM packets. With this new packet type, it is possible to tell userspace when 4 or 5 fingers are touching. Signed-off-by: Daniel Kurtz Acked-by: Chase Douglas Acked-by: Henrik Rydberg Signed-off-by: Dmitry Torokhov

Input: synaptics - process finger (<=3) transitions

2011-08-24T06:08:24Z

Synaptics image sensor touchpads track 5 fingers, but only report 2. This patch attempts to deal with some idiosyncrasies of these touchpads: * When there are 3 or more fingers, only two are reported. * The touchpad tracks the 5 fingers in slot[0] through slot[4]. * It always reports the lowest and highest valid slots in SGM and AGM packets, respectively. * The number of fingers is only reported in the SGM packet. However, the number of fingers can change either before or after an AGM packet. * Thus, if an SGM reports a different number of fingers than the last SGM, it is impossible to tell whether the intervening AGM corresponds to the old number of fingers or the new number of fingers. * For example, when going from 2->3 fingers, it is not possible to tell whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new 3rd finger). * When fingers are added one at at time, from 1->2->3, it is possible to track which slots are contained in the SGM and AGM packets: 1 finger: SGM = slot[0], no AGM 2 fingers: SGM = slot[0], AGM = slot[1] 3 fingers: SGM = slot[0], AGM = slot[2] * It is also possible to track which slot is contained in the SGM when 1 of 2 fingers is removed. This is because the touchpad sends a special (0,0,0) AGM packet whenever all fingers are removed except slot[0]: Last AGM == (0,0,0): SGM contains slot[1] Else: SGM contains slot[0] * However, once there are 3 fingers, if exactly 1 finger is removed, it is impossible to tell which 2 slots are contained in SGM and AGM. The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know. * Similarly, if two fingers are simultaneously removed (3->1), then it is only possible to know if SGM still contains slot[0]. * Since it is not possible to reliably track which slot is being reported, we invalidate the tracking_id every time the number of fingers changes until this ambiguity is resolved when: a) All fingers are removed. b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet. c) All fingers are removed except slot[0]. In this special case, the ambiguity is resolved since by the (0,0,0) AGM packet. Behavior of the driver: When 2 or more fingers are present on the touchpad, the kernel reports up to two MT-B slots containing the position data for two of the fingers reported by the touchpad. If the identity of a finger cannot be tracked when the number-of-fingers changes, the corresponding MT-B slot will be invalidated (track_id set to -1), and a new track_id will be assigned in a subsequent input event report. The driver always reports the total number of fingers using one of the EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid MT-B slots for two reasons: a) There are more than 2 fingers on the pad. b) During ambiguous number-of-fingers transitions, the correct track_id for one or both of the slots cannot be determined, so the slots are invalidated. Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP events than its maximum EV_ABS/ABS_MT_SLOT. Signed-off-by: Daniel Kurtz Acked-by: Chase Douglas Acked-by: Henrik Rydberg Signed-off-by: Dmitry Torokhov