On Sun, Oct 9, 2011 at 6:04 AM, Daniel Kurtz <djkurtz@xxxxxxxxxx> wrote: > This patch seems reasonable, but I don't think your explanation is > quite right. It is quite common for a user to move their finger > around on a trackpad for several seconds continuously. This generates > exactly the same "huge and uninterrupted stream of interrupts at a > high rate" as fingers near the pad, idle on the pad, or after the pad > is lifted. In other words, the peak *packet rate* is the same in > absolute or relative mode. You are right in that the peak packet rate is the same in both modes, but you are missing the key behavioural difference that is the reason for this patch. Here is an experiment you can do to see this for yourself: 1. Put the mouse in Absolute mode and enable packet logging 2. Without putting your finger near the pad, press and hold the left mouse button for exactly 1 second 3. Release the mouse button 4. Count how many packets were sent by the device. Now do the same for Relative mode. The results are that in the Absolute mode you will get 80 identical packets saying "the left mouse button is pressed" and then you will get 80 identical packets saying "no mouse buttons are pressed". In Relative mode you will get exactly two packets: mouse button pressed, followed by a pause, followed by mouse button unpressed. The same applies for movement. In Absolute mode, if you have your finger on or near the pad, the device will spam you with packets at the maximum rate, even if the new packet being sent is identical to the old one, or identical to the last hundred (i.e. no movement or pressure change). In Relative mode, the mouse only sends packets if it has some kind of change (in movement or button state) to communicate. Even when moving your finger very fast over the pad it is difficult to get Relative mode to hit the full packet rate. There are always a few points where the device takes a breather because it hasn't got movement to report, so the transmitted packet rate is a little less than the maximum available. This is really useful for us because we share the communication channel with the keyboard, so when the mouse takes a breather it's a good time for the keyboard packets to come through. I have confirmed with Synaptics that this behaviour is by design, it is even clearly documented in section 3.2 of the document you link to. They also confirmed that you can't turn this spammy behaviour off in absolute mode, and suggested that if we wanted to avoid this then we should use relative mode. I'm also aware of the packet size option - we want to reduce that to 40 even with relative mode, again for lower processing and power saving reasons, I guess there are other embedders who will want the same. Thats another advantage of this patch - previously you couldn't run the mouse in relative mode (i.e. no synaptics driver) while being able to reduce the mouse rate (which is done by the synaptics driver via the mechanism you describe). Thanks, Daniel -- 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
