[Xcb] XKB once again

[Thomas Hunger]

> 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? 

XKB has stuff like a list of structs with variable length
(e.g. a struct which contains a list and optional fields). 

One example can be seen in the struct KB_SETKEYTYPE used in the 
request XkbSetMap.

Now we could add a struct-creation api which works analoguous to the 
request calls. The following function would create a struct with 
variable length list members:

keytype = create_kb_setkeytype(mask, realmods, vmods, 
                               numlvels, nmapentries, preserve, 
                               list_of_mapentries, list_of_moddef);

Now we need to pass a list of these structs to xcb_send_request. This 
is a new situation because we have an array of pointers to structs 
which need to be placed in adjacent memory:

    kb_setkeytype* types;

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. 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.

e.g. 

  [...]
  xcb_parts = malloc(sizeof(struct iovec)*(n_parts+n_list_items)));

  for (i = 0; i < n_list_items; i++) {
    xcb_parts[i*2].iov_base =(char*) types[i];
    xcb_parts[i*2].iov_len = kb_setkeytype_size(types[i]);
    xcb_parts[i*2+1].iov_base = 0;
    xcb_parts[i*2+1].iov_len = -xcb_parts[2].iov_len & 3;
  }
  [...]
  free(xcb_parts);

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.

Does anyone have objections/opinions on this? Maybe someone alraedy 
did some work?

Tom