[Xcb] Vendor Requests in GLX

Jeremy Kolb jkolb at brandeis.edu
Sun May 15 12:39:50 PDT 2005


Jamey Sharp wrote:
> 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
> 
> _______________________________________________
> xcb mailing list
> xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb

How will this look from the external view?  As in how should I define 
these requests in the xml and send them with GLXVendorPrivate?

Jeremy


More information about the xcb mailing list