Draft XI 2 protocol specification

[Peter Hutterer]

On Wed, Jan 14, 2009 at 04:32:28PM +0100, Simon Thum wrote:
> 
> some rants from me:
> >     ┌───
> >         XIDeviceHierarchyEvent:
> >             GENERICEVENTDATA
> >             flags:                      SETofHIERARCHYMASK
> >             ndevices:                   CARD16
> >             ───
> >             devices:                    LISTofINT16
> >     └───
> > 
> >     HIERARCHYMASK { MasterAdded, MasterRemoved, SlaveAttached, SlaveDetached,
> >                     SlaveAdded, SlaveRemoved }
> > 
> >     type is XI_HierarchyChangedNotify.
> >     flags specifies all types of hierarchy modifiations that have occured.
> >     ndevices specifies the number of devices.
> >     devices is the list of all devices affected by this hierarchy change.
> Why not list hierarchymask and device pairs, guaranteeing one-bit only
> there, plus the accumulated SetOfHierarchyMask (for easy filtering)?
> This could lessen the cases where clients need to roundtrip since they
> could track the hierarchy given event information.

I'm not quite sure I understand what you mean. You're saying flags should be
the accumulated mask, and the event should include all (mask + deviceid) pairs
that detail the changes made? If so, yes - definitely an option and I'll try
to spec something decent out.

> >     Relative Motion event.
> >     type is XI_RelativeMotion
> >     This event is sent regardless of clipping and always provides the
> >     device-specific data. Pointer acceleration does not affect the axis
> >     values.
> There should be means of observing pointer accel or other translations,
> IMO. Maybe I missed them?
> I think a raw/cooked approach as discussed in your interactive session
> at XDS would be best, ideally indicating what has been baked into the
> cooked value (accel, flipping, rotation, ...).

I remember now. We said that we can basically include axis information twice,
once in its raw state, unclipped and unaccelerated, once in its processed
form. In GPE, both forms are easily accessible, so stuffing that in may not be
too hard.

> > - device controls in XI2? Really? (see Presence event)
> I'd view them as superseded by properties + MPX. They now mainly expose
> unused classes and questionable attributes anyway, e.g. allow to change
> the absolute class (see next rant) or axis resolution (which, of course,
> has no effect I could determine).

The device resolution has no effect because AFAIK none of the drivers actually
support it. I am tempted to get somewhat close to the linux kernel's event
interface (in spirit anyway), but so far I have nothing to show in this area.

btw. ProximitClass' purpose is merely to inform which device may generate
proximity events.

> > - still no subpixel precision, unless we decide to make the valuators 24.8, or
> >   provide 32+32 or something.
> Since most ppl will ignore subpixel, 32+32 is my favorite. Easy for
> everyone.

I think 16.16 for screen coordinates is definitely viable.
For actual axis information it's more tricky. Absolute axes with a defined
range are easy enough as integers, as scaling and thus subpixel information
has to be achieved on the client side anyway.
Relative axes are more complicated as they lack a defined axes range. One
option would be the definition of a per-axis scaling factor as part of the
device capabilities. Data in the valuators is then always INT32, multiplied by
this scaling factor (for many devices this scaling factor is probably 1
anyway).
This gives us the ability to do subpixel precision with an arbitrary per-axis
subpixel resolution. But then again, the same can be achieved by just using
floats in the first place.

Just thinking out aloud here.

Cheers,
  Peter