[Xcb] GSoC 2009: XKB and XI2 support

[Mariusz Ceier]

Josh Triplett pisze:
> 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?
"ref" is the reference to the enum type/name, and MaxLegalKeyCode in the
example means item name to reference.

> And does the <enumref> tag appear in expression contexts?  (It
> looks that way.)
> 
Yes

>>  - 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?
> 
I was thinking how it could be implemented in C, and I have come to the
conclusion that I would need some name, also in the standard these
conditional fields have names.

>>   - bitcount - counts number of bits set or cleared, e.g.
>>       <bitcount value="1"> <fieldref>namesPresent</fieldref> </bitcount>
> 
> What does the "value" attribute mean here?
> 
it means which bits to count, (expr&(1<<bit)) == (value<<bit)

> 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?
> 
The same answer as for 'if'.

> I agree that this seems somewhat redundant with if.  Let's not add this
> if it doesn't prove necessary.
> 
And I didn't use it anywhere, so this one is not important.

>>      - 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)
> ?
> 
Fields in <bitcase> are included if ( (switch expression) & ( expression
in bitcase ) == ( expression in bitcase ) )
<case> and <bitcase> both are in <switch>, and they distinguish between
two variants of <switch>, for <case> fields in <case> are included if (
(switch expression ) == (case expression ) )

>>  - 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.)
> 
<op> tag requires two arguments.

>>  - 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?
maybe xcb_xkb_get_map_reply_t if it is fixed length.

> 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.
> 
Yes, I know, I think when <if> and <switch> will be implemented, dealing
with variable length fields followed by fixed length fields, would not
be issue.

Mariusz Ceier