On Tue, Apr 17, 2012 at 01:21:45AM +0300, George Pantalos wrote: > I have noticed that the sync bit can at times be set in the second packet of > the sequence. Couldn't this reset the position to priv->multi_packet=0 when > in fact we are in priv->multi_packet=1 position? > I have also thought about "if((packet[6] & 0x40) && (priv->multi_packet == > 0))" so that sync is not lost. I think there are two possibilities for when you see the sync bit set in the second packet. The first is that the touchpad aborted the previous sequence and started a new one. In this case you really do want to reset priv->multi_packet. The other option is that it really isn't a sync bit, and that it has some other meaning. In that case you'll need to find some other reliable method for assembling the MT data in the correct order. The only way you'll be able to tell is by inspecting the packets after the one with the unexpected sync. I suspect you'll either see one of two sequences. This one: sync -> sync -> non-sync -> non-sync -> sync -> ... Which would appear to be an aborted sequence followed by the start of a new one. Or this one: sync -> sync -> non-sync -> sync -> ... Which would appear to indicate that what we're calling the sync bit isn't really a sync after all. Seth -- 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
