[RFC] xserver: Masked valuators, DIDs, and ABS_MT_SLOT

[Peter Hutterer]

On Mon, Jul 05, 2010 at 09:49:32PM -0400, Chase Douglas wrote:
> On Tue, 2010-07-06 at 11:34 +1000, Peter Hutterer wrote:
> > On Mon, Jul 05, 2010 at 09:15:42PM -0400, Chase Douglas wrote:
> > > On Tue, 2010-07-06 at 11:04 +1000, Peter Hutterer wrote:
> > > > On Thu, Jul 01, 2010 at 06:36:18PM -0400, Chase Douglas wrote:
> > > > >       Add extra functions for masked valuator input API
> > > > 
> > > > yes, but no :)
> > > > idea is right, implementation needs work. Please send this as a patch for
> > > > better comments. Most notably, you don't need GetPointerEventsM, just change GPE to take
> > > > the mask bits and fix up the callers in the DDXs.
> > > 
> > > I saw GPE is referenced in /usr/include/xorg/input.h, so I was afraid to
> > > modify its prototype. I certainly can change it though.
> > 
> > don't be. we don't really care about ABI guarantees across server revisions,
> > if a change makes sense add it. the only callers of GPE are the DDX's anyway
> > and they are in-tree. well, except VNC, they'll just have to live with it ;)
> 
> Ok, but then xf86PostMotionEventsP (and xf86PostMotionEvents through it)
> use GetPointerEvents. Should we just get rid of xf86PostMotionEvents and
> xf86PostMotionEventsP, requiring the modification of all the input
> modules? Or do we transform xf86PostMotionEvents and
> xf86PostMotionEventsP to create bit masks and call
> xf86PostMotionEventsM?

For now, the latter one I guess. Removing the current calls gives us a lot
of churn in the drivers for little benefit.

> > > <snip>
> > > > >       Add atom name for ABS_MT_SLOT properties
> > > > 
> > > > I'm not sure at all about this. I was hoping to abstract the slots so we
> > > > don't need to expose thos to the clients.
> > > 
> > > Given the approach that I have been taking, we have to expose the slot
> > > number to the clients. If you only send one touch data point per event,
> > > the client needs to know about its tracking data. The easiest way to do
> > > this is to just pass the ABS_MT_SLOT property from the kernel.
> > 
> > I thought the valuator number (or set of valuators) implicitly defined a
> > slot.
> 
> My original patches which were based on Ben's valuators approach created
> a device with an array of touches as arrays of valuators:
> 
> 0: Touch 0 X
> 1: Touch 0 Y
> 2: Touch 0 Pressure
> 3: Touch 1 X
> 4: Touch 1 Y
> 5: Touch 1 Pressure
> ...
> 
> That limits us when we get to a device that supports many properties per
> touch and many touches. We only have 36 valuators, and there are some
> devices that support more than 10 touches.
> 
> To remedy the situation, I decided that every touch that changed would
> be sent as its own event. One of the valuators would be the Abs MT Slot
> which would help the client track the touch. This also allows us to
> propagate touches directly to clients they should be sent to, instead of
> to wherever the first X and Y coordinates are. So event propagation
> *just works* with no extra effort.

how do you transmit the destruction of the touchpoint then? I'm starting to
get lost in the different implementation and approaches. It was tracking ID
at some point, then just valuator presence, and now?

Cheers,
  Peter