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. -- 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
