[RFC] Multitouch support, step one
jeremyhu at freedesktop.org
Mon Mar 15 11:40:19 PDT 2010
On Mar 15, 2010, at 09:01, Simon Thum wrote:
> 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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3333 bytes
Desc: not available
More information about the xorg-devel