[Xcb] XKB

[Christoph Reimann]

Hi, sorry I have been silent for so long and kept you waiting !
I was busy handling special cases and debugging the last few weeks, and -
finally - xkb.c and xkb.h can be generated from xkb.xml and compiled. I am
not done with testing though, but at least regular request & replies as well
as those with 'simple' (i.e. not nested) switch statements seem to be
working.
If you are interested, grab a copy of libxcb and xcb-proto (branch
gsoc2010):
        http://cgit.freedesktop.org/~chr


Following is a description of the most relevant changes I had to make:

1. Special cases
The generator should now be able to handle the following special cases that
appear in xkb.xml:
- switch
- lists with variable size elements (was buggy/not supported)
- structs that intermix variable and fixed size fields (was not supported)

2. valueparams
When replacing valueparam with switch (see commit 9895 in xcb-proto for an
example), the existing request interface does not change. However, a set of
new request functions are introduced that end on _aux (or _aux_(un)checked,
respectively). These functions take a newly introduced structured datatype
that is especially and exclusively generated for switch. It has the
following features:
- all fields (fixed as well as variable size) are included as struct members
- variable size fields appear as pointers
- nesting switch is supported
These structs are easy to manipulate and are in fact modeled after the
corresponding data types in xcb-util/aux, i.e. the aux module might be
partially replaced by replacing valueparam with switch.

3. new functions
A set of four new (automatically generated) functions is introduced:
- _serialize() takes a structured datatype and turns it into a byte stream
- _sizeof() takes a byte stream, interprets it as a certain datatype and
returns its size
- _unpack() takes a byte stream representing a switch structure, and fills
fields in the special switch datatype from it
- _unserialize() takes a byte stream and performs 'certain operations' (like
reordering fields in the special case of intermixed variable and fixed size
fields so they match XCB's data structures)
The only functions a user of XCB has to call are _unpack(), the rest is
supposed to be used internally.
Especially _unserialize() gets called automatically in the reply function.

4. changes in xkb.xml
I had to extend xkb.xml in one case: In order to get a meaningful
representation in case of complicated switch definitions, I introduced an
optional 'name' tag for bitcase (see commit dd22 in xcb-proto). Here
'optional' means that if you give bitcase a name, the C switch datatype gets
nested and the inner structs get the bitcase names, while without the name
tag, all fields get included directly in the C switch struct. This is
necessary in order to support backwards compatibility w.r.t. to valueparam
as well as avoiding field name collisions.
It might also be a good idea to add another (optional) tag to switch itself:
Currently a switch that is obtained from rewriting valueparam yields s.th.
like 'const void * value_list' as a parameter in the request functions,
where it should be 'const uint32_t value_list'. The uint32_t type was
inferred automatically whenever valueparam was hit. One could get it back by
introducting an optional tag like 'fixed_type', stating that all bitcase
fields should have the same type in the language mapping.

5. accessors/iterators:
It is not trivially possible to get the size of a switch byte stream. One
could use the _sizeof() function of course, but in order to evaluate switch,
always additional parameters have to be supplied (keep in mind that switch
stands for conditional inclusion of fields). These additional parameters do
not fit within the existing interface for iterators. However at the moment
it is not necessary to have iterators for switch, as no lists of switch
statements exist in the spec. Accessors should be working without further
modifications, however there are no accessors for switch fields as these as
well would require additional parameters.

As always looking forward to your comments and bug reports!

Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20100808/dd7455bb/attachment.html>