On Mar 15, 2010, at 09:01, Simon Thum wrote: > Henrik, > > if I'm anywhere near understanding this, then probably your're missing > an important point. This is _step one_. Getting information to where you > need it and giving it a basic structure, roughly. > > The things you're talking about are more suited as a step two: Making > sense of the information. Along those lines, you're probably right, > though I'd go even further. But ATM concensus is needed how to transport > MT information in a suitable and forward-compatible manner. > > The sooner this is nailed down, the sooner more abstract concepts can be > tackled. > > Cheers, > > Simon
I agree that application developers want something higher level. The structure that Henrik describes will be more beneficial to application developers. The point now is to determine who actually provides that data. Do we want tracking and grouping to be handled by the Xserver and sent to the client as such, or do we want to send the raw data to the client and have a library interpret these data and provide the client with these pretty structures? It seems like the latter can make use of the already-existing XI2 protocol. If we try to do this all in the server and package it up for the user, will we be looking at yet another bump of XI? Can we do it in a way that will be compatible with XI2? I actually like the idea of using the valuators to send the data over the wire. Why not use the valuators to also send data like: valuator 0 = core X valuator 1 = core Y valuator 2 = multi-touch 0 tracking id valuator 3 = multi-touch 0 group id valuator 4 = multi-touch 0 x valuator 5 = multi-touch 0 y valuator 6 = multi-touch 0 pressure valuator 7 = multi-touch 1 tracking id valuator 8 = multi-touch 1 group id valuator 9 = multi-touch 1 x valuator 10 = multi-touch 1 y valuator 11 = multi-touch 1 pressure More complex data management could then be handled by a client-side library. This still does not solve the valuator limit of 32. How difficult will it be to eliminate that maximum and have no limit? --Jeremy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
