- 27 Aug, 2011 2 commits
-
-
Dmitry Torokhov authored
This will ensure that the device delivers input events only when there are users. Tested-by:
Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru>
-
Dmitry Torokhov authored
Instead of using hard IRQ and workqueue solution switch to using threaded interrupt handler to simplify the code and locking rules. Tested-by:
-
- 24 Aug, 2011 12 commits
-
-
Wanlong Gao authored
Change the placement of __init and __exit annotations to be consistent with the rest of the drivers. Signed-off-by:
Wanlong Gao <gaowanlong@cn.fujitsu.com> Signed-off-by:
-
Daniel Kurtz authored
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 <djkurtz@chromium.org> Acked-by:
Chase Douglas <chase.douglas@canonical.com> Acked-by:
Henrik Rydberg <rydberg@euromail.se> Signed-off-by:
-
Daniel Kurtz authored
"4-finger scroll" is a gesture supported by some applications and operating systems. "Resting thumb" is when a clickpad user rests a finger (e.g., a thumb), in a "click zone" (typically the bottom of the touchpad) in anticipation of click+move=select gestures. Thus, "4-finger scroll + resting thumb" is a 5-finger gesture. To allow userspace to detect this gesture, we send BTN_TOOL_QUINTTAP. Signed-off-by:
-
Daniel Kurtz authored
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 authored
Some devices are capable of identifying and/or tracking more contacts than they can report to the driver. Document how a driver should handle this, and what userspace should expect. Signed-off-by:
-
Daniel Kurtz authored
A Synaptics image sensor tracks 5 fingers, but can only report 2. The algorithm for choosing which 2 fingers to report and in which packet: Touchpad maintains 5 slots, numbered 0 to 4 Initially all slots are empty As new fingers are detected, assign them to the lowest available slots The touchpad always reports: SGM: lowest numbered non-empty slot AGM: highest numbered non-empty slot, if there is one In addition, these touchpads have a special AGM packet type which reports the number of fingers currently being tracked, and which finger is in each of the two slots. Unfortunately, these "TYPE=2" packets are only used when more than 3 fingers are being tracked. When less than 4 fingers are present, the 'w' value must be used to track how many fingers are present, and knowing which fingers are being reported is much more difficult, if not impossible. Signed-off-by: -
Daniel Kurtz authored
Synaptics makes (at least) two kinds of touchpad sensors: * Older pads use a profile sensor that could only infer the location of individual fingers based on the projection of their profiles onto row and column sensors. * Newer pads use an image sensor that can track true finger position using a two-dimensional sensor grid. Both sensor types support an "Advanced Gesture Mode": When multiple fingers are detected, the touchpad sends alternating "Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM) packets. The AGM packets have w=2, and contain reduced resolution finger data The SGM packets have w={0,1} and contain full resolution finger data Profile sensors try to report the "upper" (larger y value) finger in the SGM packet, and the lower (smaller y value) in the AGM packet. However, due to the nature of the profile sensor, they easily get confused when fingers cross, and can start reporting the x-coordinate of one with the y-coordinate of the other. Thus, for profile sensors, "semi-mt" was created, which reports a "bounding box" created by pairing min and max coordinates of the two pairs of reported fingers. Image sensors can report the actual coordinates of two of the fingers present. This patch detects if the touchpad is an image sensor and reports finger data using the MT-B protocol. NOTE: This patch only adds partial support for 2-finger gestures. The proper interpretation of the slot contents when more than two fingers are present is left to later patches. Also, handling of 'number of fingers' transitions is incomplete. Signed-off-by: -
Daniel Kurtz authored
Signed-off-by:
-
Daniel Kurtz authored
When a Synaptics touchpad is in "AGM" mode, and multiple fingers are detected, the touchpad sends alternating "Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM) packets. The AGM packets have w=2, and contain reduced resolution finger data. The SGM packets have w={0,1} and contain full resolution finger data. Refactor the parsing of agm packets to its own function, and rename the synaptics_data.mt field to .agm to indicate that it contains the contents of the last agm packet. Signed-off-by: -
Daniel Kurtz authored
Synaptics touchpads report increasing y from bottom to top. This is inverted from normal userspace "top of screen is 0" coordinates. Thus, the kernel driver reports inverted y coordinates to userspace. This patch refactors this inversion. Signed-off-by:
-
Dmitry Torokhov authored
Since touchscreen driver does not handle any events to be sent to the device we can close serio port first and then unregister the input device. Tested-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
-
Dmitry Torokhov authored
Implement open() and close() methods for the input device so that we do not start the device unless there are users listening to the events. Acked-by:
Chris Bagwell <chris@cnpbagwell.com> Tested-by:
-
- 09 Aug, 2011 2 commits
-
-
Eric Andersson authored
Signed-off-by:
Albert Zhang <xu.zhang@bosch-sensortec.com> Signed-off-by:
Eric Andersson <eric.andersson@unixphere.com> Acked-by:
Jonathan Cameron <jic23@cam.ac.uk> Reviewed-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Dmitry Torokhov authored
To allow open/ioctl(EVIOCGABS)/close use pattern for polled devices read the device in context of open() call instead of offloading the first read to a workqueue. This will ensure that once call to open() returns device would have cached reasonably recent axis values that can be retrieved via appropriate ioctl. Signed-off-by:
-
- 03 Aug, 2011 1 commit
-
-
Amy Maloche authored
Add support for pm8xx based vibrator to facilitate haptics. This module uses the ff-memless framework. Signed-off-by:
Amy Maloche <amaloche@codeaurora.org> Signed-off-by:
Anirudh Ghayal <aghayal@codeaurora.org> Reviewed-by:
-
- 25 Jul, 2011 2 commits
-
-
Dmitry Torokhov authored
We were testing wrong bit in the extended capability query. Reported-by:
-
Rakesh Iyer authored
To support key repeats, keyboard needs to be setup as an autorepeating device. Signed-off-by:
Rakesh Iyer <riyer@nvidia.com> Signed-off-by:
-
- 20 Jul, 2011 2 commits
-
-
Dan Carpenter authored
According to the comments we want to call mutex_lock() here instead of mutex_unlock(). That makes more sense. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Dan Carpenter authored
We are testing the wrong variable here. I believe tj9->input_dev is always NULL at this point, so probe() will fail. Signed-off-by:
-
- 19 Jul, 2011 4 commits
-
-
Axel Lin authored
The implementation does break from the for loop after we assign 'i' to variable 'found'. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Signed-off-by:
-
Axel Lin authored
It's not referenced outside this file so there's no need for it to be in the global name space. Signed-off-by:
-
Axel Lin authored
Make sure we are passing the same cookie in all calls to request_any_context_irq() and free_irq(). Signed-off-by:
-
Axel Lin authored
The implementation in cy8ctmg110_probe() does not properly set reset_pin and irq_pin from platform data. Let's fix it. Signed-off-by:
-
- 13 Jul, 2011 4 commits
-
-
Axel Lin authored
Signed-off-by:
-
Axel Lin authored
i2c_master_send returns negative errno, or else the number of bytes written. Signed-off-by:
-
Axel Lin authored
We only care about if there is a successful match from the table (or no match at all), so let's make dmi_check_system return immediately instead of iterating thorough the whole table. Signed-off-by:
-
Axel Lin authored
We only care about if there is a successful match from the table (or no match at all), so let's make dmi_check_system return immediately instead of iterating thorough the whole table. Make the dmi callback function return 1 then dmi_check_system will return immediately if we have a successful match. Signed-off-by:
-
- 10 Jul, 2011 3 commits
-
-
Dmitry Torokhov authored
This reduces amount #ifdeds in the code. Signed-off-by: -
David Jander authored
This patch enables fetching configuration data, which is normally provided via platform_data, from the device-tree instead. If the device is configured from device-tree data, the platform_data struct is not used, and button data needs to be allocated dynamically. Big part of this patch deals with confining pdata usage to the probe function, to make this possible. Signed-off-by:
David Jander <david@protonic.nl> Signed-off-by:
-
Edwin van Vliet authored
Constant AIPTEK_TOOL_BUTTON_PEN_MODE was defined twice. Signed-off-by:
Edwin van Vliet <edwin@cheatah.nl> Reviewed-by:
Jesper Juhl <jj@chaosbits.net> Signed-off-by:
-
- 09 Jul, 2011 1 commit
-
-
Dmitry Torokhov authored
Newer Synaptics firmware allows to query minimum coordinates reported by the device, let's use this data. Acked-by:
-
- 07 Jul, 2011 7 commits
-
-
Daniel Kurtz authored
AGM packets contain valid button bits, too. This patch refactors packet processing to parse button bits in AGM packets. However, they aren't actually used or reported. The point is to more completely process AGM packets, and prepare for future patches that may actually use AGM packet button bits. Signed-off-by:
-
Daniel Kurtz authored
Signed-off-by:
-
Daniel Kurtz authored
Synaptics touchpads indicate via a capability bit when they perform reduced filtering on position data. In such a case, use a non-zero fuzz value. Fuzz = 8 was chosen empirically by observing the raw position data reported by a clickpad indicating it had reduced filtering. Signed-off-by:
-
Daniel Kurtz authored
Set resolution for MT_POSITION_X and MT_POSITION_Y to match ABS_X and ABS_Y, respectively. Signed-off-by:
-
Ping Cheng authored
The old code may call input_sync() without sending any other events. While it will be suppressed by the input core not calling it at all is still cheaper. Signed-off-by:
-
Ping Cheng authored
Bamboo touch sets BTN_BACK, BTN_FORWARD, BTN_LEFT, and BTN_RIGHT as the default button events for tablet buttons. Change Graphire4 and old Bamboo to the same settings. Signed-off-by:
-
Ping Cheng authored
With the removal of BTN_TOOL_FINGER for tablet buttons and expresskeys, serial number is needed to distingush if the events were from a regular tool (stylus, eraser, or mouse) or the attribures (buttons, strips, or wheels) on the tablet since there are overlapped events between the tools and the tablet attributes. Signed-off-by:
-
