[Xcb] Vendor Requests in GLX

[Jamey Sharp]

Bart and I had a brief discussion yesterday about how best to make this
work. Turns out it isn't very hard; we just had to think about it a
little. We'll need Josh's help to implement it though.

Requests that take list parameters should have a scatter-gather variant;
the current API for these requests can be pretty trivially built on top
of that. In this new variant, every list parameter is replaced by an
array of struct iovec, and a count of the number of items in that array.
(The existing API for these requests becomes a simple wrapper setting up
a single stack-allocated struct iovec for each list, then passing those
and the other parameters along to the new function.)

The new function needs to sum the number of iovecs in all the provided
lists, plus 1 for the fixed-length part of the request, and malloc a new
array of struct iovec to hand to XCBSendRequest. (And free it again
before returning, of course.) Also the XCBProtocolRequest instance in
these functions will need to be non-static and non-const so its count
field can be filled in appropriately.

So Josh, can you take care of that? Thanks...

On Mon, 2005-05-09 at 00:19 -0400, Jeremy Kolb wrote:
> Jamey Sharp wrote:
> > On Sun, 2005-05-08 at 17:53 -0400, Jeremy Kolb wrote:
> >>DeleteProgramsARB
> >>      1           CARD8           opcode (X assigned)
> >>      1           17              GLX opcode (glXVendorPrivateWithReply)
> >>      2           4+n             request length
> >>      4           1294            vendor specific opcode
> >>      4           GLX_CONTEXT_TAG context tag
> >>      4           INT32           n
> >>      n*4         LISTofCARD32    programs
> > 
> > (Did they screw these up the same way they botched the QueryFB stuff, or
> > whatever we debugged recently? That 'INT32 n' is entirely redundant with
> > the request's length field, is it not?)
> 
> Not that I know of.  I don't believe that's redundant because of 
> padding.

It's a list of CARD32s - there shouldn't be any padding bytes following
it.

But that isn't really our problem, I suppose, as long as the server
implementation isn't busted.

--Jamey