[Xcb] XML description of GLX conditional reply lists

[Jeremy Kolb]

Jamey Sharp wrote:
> I was just looking again at our GLX protocol description. Several GLX
> requests currently aren't expressed well. A simple change to the C code
> lets XCB be more natural, while still backward compatible with XCB 1.0.
> But what description should go in the XML?
> 
> Here's the challenge. If GetBooleanv, for example, has only one BOOL to
> return, then it returns it in a fixed spot in the reply. Otherwise, it
> treats that fixed spot as padding and uses a list instead. Currently, a
> caller needs code like this to read the reply: [1]
> 
> 	if(xcb_glx_get_booleanv_data_length(reply) != 1)
> 		result = xcb_glx_get_booleanv_data(reply);
> 	else
> 		result = &reply->datum;
> 
> This pattern should move into xcb_glx_get_booleanv_data and friends.
> Such a change doesn't break ABI or API, because the behavior of
> xcb_glx_get_booleanv_data only changes when length is 1, and in that
> case the current implementation returns a pointer to unallocated memory.
> 
> So I know where I want to get to in the generated code, but I'm not sure
> how to get there in the XML descriptions or the XSLT. Ideas?
> 
> --Jamey
> 
> [1] Jeremy, I think the Mesa XCB port is buggy in these requests. If
> data_length is 0, then Mesa/XCB looks at datum; but if there was one
> item, my reading of server source says data_length would be 1. I think
> you were confused because on Xlib Mesa checks that reply.length is
> non-zero, but that's not the same as the field that XCB calls "n".
> 
> 
> ------------------------------------------------------------------------


Jamey,

I hate those requests so much.  As far as I know they're the only ones
with this format... I'm not sure we want to change the XML just for
these functions.  A glx utility library might be a nice thing to have
for these and other functions...

You're probably right... it could very well be buggy.  I'll take a look
sometime later this week.

Jeremy