On Monday 16 of April 2012 16:24:07 Seth Forshee wrote:

If the latency really is noticible when you stash the ST points, here's
what I'd suggest trying instead. Stash away the last set of MT data you
saw and repeat it with each of the next two ST coordinates. I suspect
that will probably work well enough, and will allow every ST point to
still be reported. And it should significantly simplify the code as
well.

I will try to do that, thanks.

If you see the sync bit set, it's _always_ the first fragment of the MT
data, so you shoule _always_ reset the position. Why should past data
have any effect on this decision?

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. 
 

This doesn't really re-sync the position, and the sync bit is sufficient
for this purpose anyway. I'd propose that if you really think checking
multi_data[4] is beneficial, use it only for validating the MT packet
before parsing it.

OK, I have tried that before, thanks for the suggestion.

Even if you use a separate case here you need to update the other
BTN_TOOL keys. The 1 to 0 transition is needed for userspace to know
that the situation has changed. Failing to report any value is not the
same as reporting a value of 0.