xb/proto portion of [PULL v3] XResource extension v1.2

[Erkki Seppala]

Somehow the original message never reached my inbox, luckily a colleague 
pointed this message out to me :).

> I'd be happier to pull this if it had a reviewed-by tag from someone
> with a bit of xcb knowledge (which is why I've cc'ed the xcb mailing list).

That would be nice. The xcb proto of the update wasn't probably 
introduced at the proper channels earlier..

> One thing I note is the comment before "QueryClientIds" says v2.0 where
> it presumably should be v1.2.

Indeed, the version number is wrong.

> I'm also unsure about the <struct name="ClientIdValue"> definition,
> where the XResproto.h header says:
>   CARD32  length B32;
>   // followed by length CARD32s

Hmm, this comment is actually wrong. According to resproto.txt it is 
followed by CARD32s, but length is in multiples of 4. In the case of PID 
its value is 4. I shall quote the passage (lines 127+ of resourceproto.txt):

CLIENTIDVALUE [ spec:   CLIENTIDSPEC
                 length: CARD32
                 value:  LISTofCARD32 ]

A data structure specifying a single client ID.

spec
     A unique identifier for a specific ID of some client. Wildcards
     such as None and bitmask unions aren't allowed. The data structure
     must always identify a single client and single ID type. However,
     the client doesn't have to be specified as the resource_base of
     CLIENTXIDRANGE and can be any resource owned by the client.
length
     Specifies the length of an ID in units of CARD32. The length
     depends on the ID type. In version 1.2 the lengths are 0 for
     ClientXid and 4 for LocalClientPid. The length of ClientXid is 0
     because that is already stored in the spec field.
value
     Actual ID data. In version 1.2 this is missing for ClientXid and
     consists of a single CARD32 for LocalClientPid.

Perhaps resourceproto.txt could be revised to state that value is 
LISTofCARD8, but how would the alignment requirements then be indicated?

> the res.xml has CARD8's instead of CARD32's:
>        <field type="CARD32" name="length" />
>        <list type="CARD8" name="client_ids">
>            <fieldref>length</fieldref>
>        </list>
>
> CARD8 seems too short for a pid_t, but perhaps I'm misunderstanding the
> xcb type handling?

Which is what is stated here: the field actually contains opaque data, 
so a pid is stored in four octets. But perhaps it should be better 
written something like (if the previous specification was revised):

   <list type="CARD32" name="client_ids">
     <op>/</op>
       <op>+</op>
         <fieldref>length</fieldref>
         <value>3</value>
       </op>
     </op>
   </list>

or not, hopefully someone can chime in. It would be nice to express that 
the padding isn't part of the data. Or does it automatically get padded 
to 4 bytes?