[RFC] XI2 draft protocol specification (v 0.1)

[Simon Thum]

Peter Hutterer wrote:
> FP1616
>         Fixed point decimal in 16.16 format as 32 bit integer. The client is
>         required to convert to 16.16 decimal format.
Maybe it's just me, but I don't really get what "16.16 decimal format"
means.

>     ┌───
>         XIChangeDeviceHierarchy
>             num_changes:     CARD8
>             changes:         LISTofHIERARCHYCHANGES
>     └───
> 
>     HIERARCHYCHANGE { CREATEMASTER, REMOVEMASTER, CHANGEATTACHMENT }
> 
>     HIERARCHYCHANGETYPE { CreateMaster, RemoveMaster, ChangeAttachment }
> 
>     CHANGEMODE { Float, Attach }
I'd split HIERARCHYCHANGE into four: CM, RM, DetachSlave, AttachSlave -
thereby getting rid of CHANGEMODE.

>     The server processes the changes one by one and applies changes
>     immediately. If an error occurs, processing stops at the current change
>     and the error is returned to the client.
The point it stopped might be interesting to the client (only if it's
easy to report)

> ┌───
>         XISetClientPointer
>             win:             Window
>             ▶
>             set:             BOOL
>             deviceid:        DEVICEID
>     └───
> 
>     Query the ClientPointer for the client owning 'win'.
I guess XI*G*etClientPointer is meant.



>     ┌───
>         RawEvent
>             EVENTHEADER
>             eventtype:                 RAWTYPE
>             detail:                    CARD32
>             buttons_len:               CARD16
>             valuators_len:             CARD16
>             buttons:                   SETofBUTTONMASK
>             valuators:                 SETofVALUATORMASK
>             valuators_unaccel:         SETofVALUATORMASK
>             axisvalues:                LISTofFP3232
>             axisvalues_unaccel:        LISTofFP3232
>     └───
> 
>     RAWTYPE { Motion, KeyPress, KeyRelease, ButtonPress, ButtonRelease }
> 
>     A RawDevice event provides the information provided by the driver to the
>     client. RawDevice events are only generated for slave devices.
>     Unaccelerated and accelerated valuator data is provided if applicable.
Of course acceleration is, right now, the only thing that could happen
to valuators after the driver is finished, but I'd avoid a direct
reference to it in the spec. (un-)transformed or adjusted seems a better
choice to me. Or 'raw'.

>     valuators
>         Bitmask of valuators provided in 'axisvalues'.
>     valuators_unaccel
>         Bitmask of valuators provided in 'axisvalues_unaccel'.
It might make sense to say something about their correlation, i.e. will
both be reported when available? The description: 'Unaccelerated and
accelerated valuator data is provided if applicable.' may mean: 'If an
axis is accelerated/translated, the server may/must omit the
untranslated value'.
IOW, what exactly is 'applicable'?