Draft XI 2 protocol specification

[Simon Thum]

Hi Peter,

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.

>     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, ...).

> - 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).

I guess a "return BadValue" implementation would hardly be noticed.

> - how do go about input classes. refurbish them?
I argue to kill AbsoluteClass and ProximityClass dead. Possibly followed
by IntegerFeedbackClass. If you ignore StringFeedbackClass (for which I
see some utility) the remaining classes make some sense and actually do
a job.

That said, the absolute stuff, when done properly, could solve problems
some users have with anisotropic devices. Current state may be fine for
tablets but may not scale well beyond, so I see no real benefit over a
driver-specific impl.

To sum it up: a set of well-defined properties plus axis labeling is
probably more scalable and implementable than the absolute class stuff
(that I've seen, at least). And for ProximityClass: just look up it's
definition :)

However, some day there should be a non-racy multi prop setter if you go
down that lane.

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

> - is it beer o'clock yet?

Cheers,

Simon