[RFC] Multitouch support, step one

[Peter Hutterer]

On Mon, Mar 15, 2010 at 11:40:19AM -0700, Jeremy Huddleston wrote:
> 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?

I'd vouch for the client. At least at this point we do not have enough
information from the devices to do grouping fo contacts - that is where I
think the context-specific stuff comes in. 

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

As I said, there are no protocol changes needed for this, so we don't need
an API bump. I'd like to leave the actual protocol changes and more complex
features for the general multitouch case - if we ever figure out how to do
it.
 
> 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?

in theory a simple sed will do. In practice, this is software we're talking
about...

Cheers,
  Peter