linux/drivers/input/mouse/synaptics.h, branch v4.0

Merge branch 'synaptics' into for-linus

2015-03-16T16:12:56Z

Bring in changes needed to properly handle Lenovo 2015 lineup.

Input: synaptics - re-route tracksticks buttons on the Lenovo 2015 series

2015-03-09T06:36:53Z

The 2015 series of the Lenovo thinkpads added back the hardware buttons on top of the touchpad for the trackstick. Unfortunately, they are wired to the touchpad, and not the trackstick. Thus, they are seen as extra buttons from the kernel point of view. This leads to a problem in user space because extra buttons on synaptics devices used to be used as scroll up/down buttons. So in the end, the experience for the user is scroll events for buttons left and right when using the trackstick. Yay! Fortunately, the firmware advertises such behavior in the extended capability $10, and so we can re-route the buttons through the pass-through interface. Hallelujah-expressed-by: Peter Hutterer Signed-off-by: Benjamin Tissoires Acked-by: Hans de Goede Signed-off-by: Dmitry Torokhov

Input: synaptics - retrieve the extended capabilities in query $10

2015-03-09T06:36:52Z

Newer Synaptics touchpads need to get information from the query $10. Retrieve it if available. Signed-off-by: Benjamin Tissoires Acked-by: Hans de Goede Signed-off-by: Dmitry Torokhov

Input: psmouse - use IS_ENABLED instead of homegrown code

2015-02-16T00:08:35Z

Instead of having various protocols provide _supported() functions, let's use IS_ENABLED() macro that works well in "if" statements. Acked-by: Hans de Goede Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov

Input: synaptics - use in-kernel tracking for reporting mt data

2014-12-29T22:23:00Z

The current code tries to consider all states and transitions to properly detect which finger is attached to which slot. The code is quite huge and difficult to read. If the sensor manages to group the touch points but is not reliable in giving tracking ids, we can simply use the kernel tracking method. Note that it is already used by Cr-48 Chromebooks. Incidentaly, this fixes a bug reported by Peter Hutterer: """ on the Lenovo T440, run: evemu-record /dev/input/event4 | grep BTN_ then put one, two, three, two fingers down when you go from 3 to 2 fingers the driver sends a spurious BTN_TOUCH 0 event: E: 0.000000 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 0.000000 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 0.770008 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 0.770008 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 1.924716 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 1.924716 0001 014e 0001 # EV_KEY / BTN_TOOL_TRIPLETAP 1 .. changing from 3 to 2 fingers now E: 3.152641 0001 014a 0000 # EV_KEY / BTN_TOUCH 0 E: 3.152641 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 3.152641 0001 014e 0000 # EV_KEY / BTN_TOOL_TRIPLETAP 0 E: 3.176948 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 quick look in the kernel shows it's caused by hw.z going to 0 for a packet, so probably a firmware bug. either way, it makes it hard to track BTN_TOUCH as signal that at least one finger is down. """ The in-kernel tracking is enough to remove this spurious BTN_TOUCH 0. Signed-off-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov

Input: synaptics - gate forcepad support by DMI check

2014-10-11T18:34:42Z

Unfortunately, ForcePad capability is not actually exported over PS/2, so we have to resort to DMI checks. Cc: stable@vger.kernel.org Reported-by: Nicole Faerber Signed-off-by: Dmitry Torokhov

Input: synaptics - add support for ForcePads

2014-09-09T23:52:28Z

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. Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede 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

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: 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