[Xcb] XKB once again

[Jamey Sharp]

On 9/3/07, Thomas Hunger <hto at arcor.de> wrote:
> > a) I think the question is more about the weird packing
> >    that's going on here?  The real question is whether the
> >    client or XCB does the packing: I'm inclined toward the
> >    former, but only barely.
>
> This is actually a good question: who is responsible for packing data?
> ...
> Now we could add a struct-creation api which works analoguous to the
> request calls.

We have the same question in the core protocol and several other
extensions. So far, we've always chosen that the client needs to pack
the data for wacky structures, which means that the request functions
all take BYTE arrays. This is kind of unfortunate as it makes XCB harder
to use.

Ian has done some good work on making this easier for the clients. I'm
surprised he didn't mention it already. See xcb/util/renderutil/glyph.c
and the callers of pack_list in xcb/util/convenient/xcb_aux.c. I'd like
to see his work generalized and applied to more of these XCB API warts.

> Right now lists are passed via xcb_parts to xcb_send_request. I
> propose that we keep this but change its usage where needed as
> follows: xcb_parts is not allocated on the stack anymore but via
> malloc.

Using malloc isn't strictly necessary. Most platforms support using
either alloca or C99 variable-length arrays to stack-allocate an array
with size known only at runtime.

> If a list of structs with variable lengths is passed, we
> allocate one xcb_part for each struct and fill the xcb_pary-array
> with a for-loop.

We've needed functionality like this for a long time, to support use
cases like Mesa on GLX. Mesa has large data structures passed to it by
applications, and it often needs to pack several of them into one
request. Ideally it would pass all these structures directly to XCB.
However, we usually can't represent those as anything more than arrays
of bytes, and it makes the most sense to pass an array of 'struct iovec'
down and just memcpy it in the request function.

The code generator currently generates functions that accept BYTE
arrays. I'd like it to continue doing so, even for these XKB requests.
But I'd like to add something like the kind of request function you
propose, as an alternative.

> The request function would steal the reference to keytype which was
> created by create_kb_setkeytype (see above), freeing the user from
> memory-management at this place.

The request function should not free any of the caller's memory. It's a
good way to surprise programmers with double-free bugs, and anyway the
caller might wish to reuse those structures.

--Jamey