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): <a href="http://cgit.freedesktop.org/~chr">http://cgit.freedesktop.org/~chr</a> 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 <a href="http://s.th">s.th</a>. 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