[Xcb] [RFC PATCH proto] XKB-fixes (preliminary version)

[Ran Benita]

On Sat, Mar 14, 2015 at 11:44:01AM +0100, Christian Linhart wrote:
> This is an informal patch ( not to be merged ) to show
> what I have found in XKB.

Ugh, for some reason this went to my spam folder so I almost missed it.

I scanned through the changes, they all seem to make sense to me. That's
very in-depth work!

I'll wait for the split-up patches to review for correctness and
compatability. At worst, we'll indeed just have to create some new xml
file.

> Among other things, the following probably needs to be done:
> * some changes in the generator
>   - support structs with only varsized fields
>     Currently, this generates an empty C-struct.
>     I have once made a patch for that, but I need to adapt it to
>     current upstream.
> 
>   - Maybe support size of var-sized unions.
>     Or better: we replace the unions by switch-case, see further below.
>     Var-sized unions are hard because there is no
>     definition which union field to choose.
>     (just possibly heuristics but that's ugly)
> 
>   - ...
> 
> * event numbers work differently in XKB than in other extensios.
>   This should be reflected by the XML.
> 
> * replace unions by switch-case. Especially Doodad.
>   Unions are deprecated and they do not fully describe the protocol
>   because there is no info in the XML which union field to choose.
>   We need switch-case anyways for replacing unions with var-sized members.
> 
> * testing
>   (I have only tested with my own generator, not with libxcb)
> 
> * review against the spec and xlib/xserver implementation.
> 
> * review ABI/API compatibility with respect to usage in
>   important software like QT.
>   Then decide whether to make a second version of XKB support.

This all sounds like a good plan. I have a small suggestion: don't wait
until you get all of these things right before you send all of the
patches. Below you have many small correctness fixes (e.g. alignments)
and improvements (e.g. using the right enum mask) which I think you can
send out already. That will reduce the amount of changes you need to
handle, and we can also help with double-checking against the spec, etc.

> * ...

I have run into one more problem with the generated API itself, which
renders requests like xkb_set_map_aux() impossible to use in practice.
The problem is that there is no way (I think) to generate the last
argument `const xcb_xkb_set_map_values_t *values`. But, it'll be better
to discuss that in a separate bug so I'll do that.

Ran