[Xcb] GSoC 2009: XKB and XI2 support
mceier at gmail.com
Wed Sep 16 01:18:19 PDT 2009
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
"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.)
>> - if - conditional inclusion of fields, based on expression, it always
>> is the last field of struct, e.g.
>> <if name="ifHasPreserve">
>> <!-- expression -->
>> <!-- fields for inclusion -->
>> <list > ...
> Using the first child of the if as the conditional expression seems
> quirky, but preferable to requiring an extra tag around the conditional
> 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">
>> 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.
> 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
Yes, I know, I think when <if> and <switch> will be implemented, dealing
with variable length fields followed by fixed length fields, would not
More information about the Xcb