[Xcb] GSoC 2009: XKB and XI2 support

[Josh Triplett]

On Tue, Sep 15, 2009 at 11:55:16AM +0200, Mariusz Ceier wrote:
> Julien Danjou pisze:
> > As you may know, Marius Ceier has been a Google sponsored student
> > working on XCB this summer.
> > 
> > He wrote XML files describing XKB and XI2 protocol. He also had to do
> > XKB2, but since the spec were not finished in time, he was not able to
> > do that. AFAIK, he also touched some other part needed to make XKB and
> > XI2 work, mostly the Python C code generator.

Sounds very awesome; we definitely need to support those extensions, and
they've proven quite hard in the past.

>    I would need some RFC on new tags that I introduced for XKB, from the
> point of view of code generators of different languages.
> Now I will describe these tags here briefly:
>  - enumref - it's a reference to already declared enum item e.g.
>    <enumref ref="Const">MaxLegalKeyCode</enumref>

The concept of an enumref seems fine.  What does the "ref" attribute
mean?  And does the <enumref> tag appear in expression contexts?  (It
looks that way.)

>  - if - conditional inclusion of fields, based on expression, it always
> is the last field of struct, e.g.
>    <if name="ifHasPreserve">
>        <!-- expression -->
>        <fieldref>hasPreserve</fieldref>
>        <!-- fields for inclusion -->
>        <list > ...

Nice!

Using the first child of the if as the conditional expression seems
quirky, but preferable to requiring an extra tag around the conditional
expression.

Why does the if need a name?

>   - bitcount - counts number of bits set or cleared, e.g.
>       <bitcount value="1"> <fieldref>namesPresent</fieldref> </bitcount>

What does the "value" attribute mean here?

This operation usually seems to go by the name "popcount"; XCB calls it
that, as does the x86 instruction set.

>   - switch - conditional inclusion of fields, in 2 variants:
>      - case - include exactly one set of fields that matches ( equaltity
> comparison ) e.g.:
> 	<switch name="switchX">
>              <value>3</value>
>              <case>
>                  <value>1</value>
>                  <fieldref>x</fieldref>
>              </case>
>              <case>
>                  <value>3</value>
>                  <fieldref>y</fieldref>
>              </case>
>         </switch>
>       in this example only y field will be included. This variant is a
> bit redundant - it can be replaced by if tag, so I didn't use it ...

Same question: why the "name" attribute?

I agree that this seems somewhat redundant with if.  Let's not add this
if it doesn't prove necessary.

>      - bitcase - include all that matches, in the example above, when
> 'case' is renamed to 'bitcase', x and y fields would be included in
> struct. I used this a lot.

Sounds fairly reasonable, given the common approach of using flags to
specify items.  In fact, it could potentially replace <valueparam> in
some cases.

Checking that it has the obvious semantics: the fields inside a given
<case> get included if
(top-level bitcase expression value) & (case expression value) == (case expression value)
?

>  - neg - bit negation, e.g.
>     <neg><fieldref>clear</fieldref></neg>

This should use something like the existing <op> tag, with ~ as the
operator.  (I don't know if <op> works for unary operations, though, so
that needs some thought.)

>  - sumof - sumation of elements of list, e.g.
>     <sumof ref="nLevelsPerType" type="CARD16" />

This seems somewhat specialized.  Specialization does seem *potentially*
preferable to providing general-purpose programming language features,
unless of course we end up providing umpteen specializations.

I guess sumof seems fine.

>  - replyof - makes copy of reply of given request a field of other
> request, e.g.
>     <replyof request="GetMap" name="map" />

Seems fine.  I find it a little unfortunate that we can't just use
<field> to define this, but then what would go in the type attribute?
We need some way to reference the type of the reply structure, and this
seems acceptable.

Obviously you'll have to deal with variable-length replies carefully
here.

- Josh Triplett