Re: ALPS v4 Semi-mt Support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux