[Xcb] Vendor Requests in GLX

[Jamey Sharp]

On Sun, 2005-05-15 at 15:39 -0400, Jeremy Kolb wrote:
> Jamey Sharp wrote:
> > 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.
> 
> How will this look from the external view?  As in how should I define 
> these requests in the xml and send them with GLXVendorPrivate?

Under this proposal the vendor private requests still won't be declared
in the XML protocol description; you should be done with that part. Code
that looks like this using Xlib:

        GLubyte const * pc = __glXSetupVendorRequest(gc,
        	X_GLXVendorPrivateWithReply,
        	X_GLvop_AreTexturesResidentEXT, cmdlen);
        (void) memcpy((void *)(pc + 0), (void *)(&n), 4);
        (void) memcpy((void *)(pc + 4), (void *)(textures), (n * 4));

Would look roughly like this with the new API:

        XCBGlxVendorPrivateWithReplyCookie cookie;
        struct iovec list[2];
        list[0].iov_base = &n;
        list[0].iov_len = 4;
        list[1].iov_base = textures;
        list[1].iov_len = n * 4;
        cookie = XCBGlxVendorPrivateWithReplyV(c,
        	X_GLvop_AreTexturesResidentEXT,
        	gc->currentContextTag, 2, list);

Note that the implementation as I defined it above will pad each iovec
chunk out to a 4-byte boundary (though the above code won't exercise
that). This means it won't play nicely with PolyText8 or PolyText16, for
example, which is disappointing as those were examples I was
particularly hoping to support cleanly.

--Jamey