- 08 6月, 2014 1 次提交
-
-
由 Benjamin Tissoires 提交于
commit 421e08c4 fixed the reported min/max for the X and Y axis, but unfortunately, it broke the resolution of those same axis. On the t540p, the resolution is the same regarding X and Y. It is not a problem for xf86-input-synaptics because this driver is only interested in the ratio between X and Y. Unfortunately, xf86-input-cmt uses directly the resolution, and having a null resolution leads to some divide by 0 errors, which are translated by -infinity in the resulting coordinates. Reported-by: NPeter Hutterer <peter.hutterer@who-t.net> Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 27 5月, 2014 3 次提交
-
-
由 Hans de Goede 提交于
Most of the affected models share pnp-ids for the touchpad. So switching to pnp-ids give us 2 advantages: 1) It shrinks the quirk list 2) It will lower the new quirk addition frequency, ie the recently added W540 quirk would not have been necessary since it uses the same LEN0034 pnp ids as other models already added before it As an added bonus it actually puts the quirk on the actual psmouse, rather then on the machine, which is technically more correct. Cc: stable@vger.kernel.org Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
This is a preparation patch for simplifying the min/max quirk table. Cc: stable@vger.kernel.org Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
The T540p has a touchpad with pnp-id LEN0034, all the models with this pnp-id have the same min/max values, except the T540p where the values are slightly off. Fix them to be identical. This is a preparation patch for simplifying the quirk table. Cc: stable@vger.kernel.org Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 15 5月, 2014 1 次提交
-
-
由 Hans de Goede 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1096436 Cc: stable@vger.kernel.org Tested-and-reported-by: ajayr@bigfoot.com Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 24 4月, 2014 1 次提交
-
-
由 Hans de Goede 提交于
Cc: stable@vger.kernel.org Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 20 4月, 2014 2 次提交
-
-
由 Hans de Goede 提交于
We expect that all the Haswell series will need such quirks, sigh. The T431s seems to be T430 hardware in a T440s case, using the T440s touchpad, with the same min/max issue. The X1 Carbon 3rd generation name says 2nd while it is a 3rd generation. The X1 and T431s share a PnPID with the T540p, but the reported ranges are closer to those of the T440s. HdG: Squashed 5 quirk patches into one. T431s + L440 + L540 are written by me, S1 Yoga and X1 are written by Benjamin Tissoires. Hdg: Standardized S1 Yoga and X1 values, Yoga uses the same touchpad as the X240, X1 uses the same touchpad as the T440. Cc: stable@vger.kernel.org Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD property for for touchpads with top button areas. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 29 3月, 2014 2 次提交
-
-
由 Hans de Goede 提交于
This extends Benjamin Tissoires manual min/max quirk table with support for the ThinkPad X240. Cc: stable@vger.kernel.org Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Benjamin Tissoires 提交于
The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad. However, these new Synaptics devices report bad axis ranges. Under Windows, it is not a problem because the Windows driver uses RMI4 over SMBus to talk to the device. Under Linux, we are using the PS/2 fallback interface and it occurs the reported ranges are wrong. Of course, it would be too easy to have only one range for the whole series, each touchpad seems to be calibrated in a different way. We can not use SMBus to get the actual range because I suspect the firmware will switch into the SMBus mode and stop talking through PS/2 (this is the case for hybrid HID over I2C / PS/2 Synaptics touchpads). So as a temporary solution (until RMI4 land into upstream), start a new list of quirks with the min/max manually set. Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> CC: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 13 8月, 2013 1 次提交
-
-
由 Sachin Kamat 提交于
__initconst should be placed between the variable name and equal sign for the variable to be placed in the intended section. Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 05 6月, 2013 1 次提交
-
-
由 Eric Miao 提交于
In summary, the symptom is intermittent key events lost after resume on some machines with synaptics touchpad (seems this is synaptics _only_), and key events loss is due to serio port reconnect after psmouse sync lost. Removing psmouse and inserting it back during the suspend/resume process is able to work around the issue, so the difference between psmouse_connect() and psmouse_reconnect() is the key to the root cause of this problem. After comparing the two different paths, synaptics driver has its own implementation of synaptics_reconnect(), and the missing psmouse_probe() seems significant, the patch below added psmouse_probe() to the reconnect process, and has been verified many times that the issue could not be reliably reproduced. There are two PS/2 commands in psmouse_probe(): 1. PSMOUSE_CMD_GETID 2. PSMOUSE_CMD_RESET_DIS Only the PSMOUSE_CMD_GETID seems to be significant. The PSMOUSE_CMD_RESET_DIS is irrelevant to this issue after trying several times. So we have only implemented this patch to issue the PSMOUSE_CMD_GETID so far. Tested-by: NDaniel Manrique <daniel.manrique@canonical.com> Signed-off-by: NJames M Leddy <james.leddy@canonical.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 16 2月, 2013 1 次提交
-
-
由 Henrik Rydberg 提交于
To properly setup event parameters for emulated events, pass the appropriate flag to the slot initialization function. Also, all MT-related events should be setup before initialization. Incidentally, this solves the issue of doubly filtered pointer events. Reported-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 14 2月, 2013 1 次提交
-
-
由 Daniel Kurtz 提交于
Investigating the following gesture highlighted two slight implementation errors with choosing which slots to report in which slot when multiple contacts are present: Action SGM AGM (MTB slot:Contact) 1. Touch contact 0 (0:0) 2. Touch contact 1 (0:0, 1:1) 3. Lift contact 0 (1:1) 4. Touch contacts 2,3 (0:2, 1:3) In step 4, slot 1 was not being cleared first, which means the same tracking ID was being used for reporting both the old contact 1 and the new contact 3. This could result in "drumroll", where the old contact 1 would appear to suddenly jump to new finger 3 position. Similarly, if contacts 2 & 3 are not detected at the same sample, step 4 is split into two: Action SGM AGM (MTB slot:contact) 1. Touch contact 0 (0:0) 2. Touch contact 1 (0:0, 1:1) 3. Lift contact 0 (1:1) 4. Touch contact 2 (0:2, 1:1) 5. Touch contact 3 (0:2, 1:3) In this case, there was also a bug. In step 4, when contact 1 moves from SGM to AGM and contact 2 is first reported in SGM, slot 0 was actually empty. So slot 0 can be used to report the new SGM (contact 0), immediately. Since it was empty, contact 2 in slot 0 will get a new tracking ID. Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 29 9月, 2012 1 次提交
-
-
由 Seth Forshee 提交于
Commit c0394506 (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: NSeth Forshee <seth.forshee@canonical.com> Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org> Tested-by: NAlan Swanson <swanson@ukfsn.org> Tested-by: NArteom <arutemus@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 20 9月, 2012 1 次提交
-
-
由 Henrik Rydberg 提交于
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: NBenjamin Tissoires <benjamin.tissoires@enac.fr> Tested-by: NPing Cheng <pingc@wacom.com> Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
-
- 25 7月, 2012 1 次提交
-
-
由 Seth Forshee 提交于
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: NSeth Forshee <seth.forshee@canonical.com> Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 08 7月, 2012 1 次提交
-
-
由 Daniel Kurtz 提交于
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: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 11 5月, 2012 1 次提交
-
-
由 JJ Ding 提交于
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: NJJ Ding <dgdunix@gmail.com> Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 21 4月, 2012 1 次提交
-
-
由 Benjamin Herrenschmidt 提交于
commit 7968a5dd 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: NBenjamin Herrenschmidt <benh@kernel.crashing.org> CC: stable@kernel.org [3.3] Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 12 12月, 2011 1 次提交
-
-
由 Dmitry Torokhov 提交于
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: NDaniel Manrique <daniel.manrique@canonical.com> Tested-by: NDaniel Manrique <daniel.manrique@canonical.com> Cc: stable@kernel.org Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 16 11月, 2011 1 次提交
-
-
由 Daniel Drake 提交于
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: NDaniel Drake <dsd@laptop.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 10 11月, 2011 1 次提交
-
-
由 Daniel Drake 提交于
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: NDaniel Drake <dsd@laptop.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 11 10月, 2011 1 次提交
-
-
由 Dmitry Torokhov 提交于
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: NWanlong Gao <gaowanlong@cn.fujitsu.com> Reviewed-by: NJJ Ding <dgdunix@gmail.com> Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 24 8月, 2011 7 次提交
-
-
由 Daniel Kurtz 提交于
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: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Acked-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Daniel Kurtz 提交于
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: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Acked-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Daniel Kurtz 提交于
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: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Acked-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Daniel Kurtz 提交于
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: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Acked-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Daniel Kurtz 提交于
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Acked-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Daniel Kurtz 提交于
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: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Acked-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Daniel Kurtz 提交于
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: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Acked-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 10 7月, 2011 1 次提交
-
-
由 Dmitry Torokhov 提交于
Newer Synaptics firmware allows to query minimum coordinates reported by the device, let's use this data. Acked-by: NChase Douglas <chase.douglas@canonical.com> Acked-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 07 7月, 2011 4 次提交
-
-
由 Daniel Kurtz 提交于
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: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Daniel Kurtz 提交于
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Daniel Kurtz 提交于
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: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Daniel Kurtz 提交于
Set resolution for MT_POSITION_X and MT_POSITION_Y to match ABS_X and ABS_Y, respectively. Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org> Acked-by: NChase Douglas <chase.douglas@canonical.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 31 3月, 2011 1 次提交
-
-
由 Jan Beulich 提交于
'struct dmi_system_id' arrays must always have a terminator to keep dmi_check_system() from looking at data (and possibly crashing) it isn't supposed to look at. The issue went unnoticed until ef8313bb, but was introduced about a year earlier with 7705d548 (which also similarly changed lifebook.c, but the problem there got eliminated shortly afterwards). The first hunk therefore is a stable candidate back to 2.6.33, while the full change is needed only on 2.6.38. Signed-off-by: NJan Beulich <jbeulich@novell.com> Cc: stable@kernel.org Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 29 1月, 2011 2 次提交
-
-
On some machines, like Dell Studio XPS 16 (1640), touchpad fails to respond to the standard query after first reset but may start responding later, so let's repeat reset sequence several (3) times. Signed-off-by: NAlexandre Peixoto Ferreira <alexandref75@gmail.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
synaptics_set_advanced_gesture_mode() affect capabilities bits we should perform comparison after calling this function, otherwise they will never match and we will be forced to perform full reconnect. Signed-off-by: NAlexandre Peixoto Ferreira <alexandref75@gmail.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 23 12月, 2010 1 次提交
-
-
由 Andres Salomon 提交于
OLPC has switched to a Synaptics touchpad. It turns out that it's pretty useless in absolute mode. This patch looks for an OLPC system (via DMI tables), and refuses to init Synaptics mode in that scenario (falling back to relative mode). Signed-off-by: NAndres Salomon <dilinger@queued.net> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-