Hi Daniel, On Wed, Oct 26, 2011 at 10:25:52AM +0100, Daniel Drake wrote: > 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 through > a sysfs attribute. 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. Can we make it a separate protocol type so there is clear distinction between them? Then you could employ the standard protocol switch code instead of rolling your own. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
