In multi-touch-protoccol.txt it mentions that there are two modes:
mode A which we essentially use now (I think) were we send the contacts to the input system and call input_mt_sync() which leaves it up to the user space to associate a old contact to a new one (ie tracking id for each contact), it will use a Euclidean bipartite matching solution (see http://troodon-software.com/archives/34).
mode B you send the tracking ID of the touch via ABS_MT_TRACKING_ID (which we do), but it says to use input_mt_slot() to separate contacts rather than input_mt_sync(), since NW sent a lot of time matching contacts it seems silly to use the less accurate Euclidean bipartite methods since NW's solutions should be better.
It might be good to at least have a compile time define to choose which method we use (better yet a module parameter or even a sys interface or something).
In multi-touch-protoccol.txt it mentions that there are two modes:
mode A which we essentially use now (I think) were we send the contacts to the input system and call input_mt_sync() which leaves it up to the user space to associate a old contact to a new one (ie tracking id for each contact), it will use a Euclidean bipartite matching solution (see http://troodon-software.com/archives/34).
mode B you send the tracking ID of the touch via ABS_MT_TRACKING_ID (which we do), but it says to use input_mt_slot() to separate contacts rather than input_mt_sync(), since NW sent a lot of time matching contacts it seems silly to use the less accurate Euclidean bipartite methods since NW's solutions should be better.
It might be good to at least have a compile time define to choose which method we use (better yet a module parameter or even a sys interface or something).