[Xcb] initial glx.xml file

[Josh Triplett]

Jeremy Kolb wrote:
> Here's what I have so far after a few hours of working on it.  If this
> could get put in the repository that would be cool (though it's probably
> not good enough so far).
>
> I took the requests/replies and made all of the core GLX ones.  I didn't
> do the vendor specific stuff (SGI, NV, ARB, etc.).  I also haven't
> figured out yet what to make into enums/types yet.
>
> I haven't tested any of it (it's beyond me how to do that yet) but if
> anyone's interested here's the file, it's certainly a start.

And an excellent start at that; great work!  A few suggestions:

* If you haven't already seen it, I suggest looking at the specification
for the GLX protocol, available at
http://www.opengl.org/resources/libraries/glx.html ; specifically, the
document labelled "GLX 1.3 Protocol Encoding Spec".  This specification
is far easier to follow than a header file, and includes complete
descriptions of the wire layout.

* In particular, looking just at the header file can be misleading,
because you don't generally see the variable-length portions of
requests, which come after the request structure.  Many of the requests
in the GLX protocol have variable-length data.

* Please don't copy any parts of the current OpenGL headers; they are
under 'SGI's Free Software License "B"', which despite the name is not a
Free Software license (at a minimum, it requires you to notify SGI if
you learn of possible infringement, and has an overly-broad indemnity
clause).  Don't copy stuff from the specification document either, as
its license is far worse.  Structure layouts are certainly not
copyrightable, but comments and other text are.

* Also licensing-related: please go ahead and put the standard XCB
license header at the top of your source file.  Grab the version from
xproto.xml, and change the name in the copyright notice to your own.

> 1/18/2005 - Initial version (core requests/replies I think)
> 	All the vendor stuff I ignored, not sure if I should add that or not.

I wouldn't suggest trying to add all the structures that get passed in
the VendorPrivate calls or the Render calls, nor all the requests for
non-rendering commands, at least not for now.

> 	<typedef oldname="CARD32" newname="ContextID" />
>     <typedef oldname="CARD32" newname="Pixmap" />
> 	<typedef oldname="CARD32" newname="Drawable" />
> 	<typedef oldname="CARD32" newname="Pbuffer" />
> 	<typedef oldname="CARD32" newname="Window" />
> 	<typedef oldname="CARD32" newname="FBConfigID" />
> 	<typedef oldname="CARD32" newname="FBConfigIDSGIX" />
> 	<typedef oldname="CARD32" newname="PbufferSGIX" />

For Pixmap, Drawable, and Window, XCB already has definitions in
xcb_types; please use these.  (xcb_types is referenced automatically, so
you don't need to do anything to gain access to those types.)  Also,
they are in all-caps (PIXMAP, DRAWABLE, WINDOW).

> 	<!-- Not sure about this one, it lacks an opcode -->
> 	<request name="Single">
> 		<field type="CARD32" name="contextTag" />
> 		<reply>
> 			<pad bytes="1" />
> 			<field type="CARD32" name="retval" />
> 			<field type="CARD32" name="size" />
> 			<pad bytes="16" />
> 		</reply>
> 	</request>

This isn't actually a request; it's just the common prefix of all the
non-rendering command requests.  As I said above, I wouldn't worry about
those for now, so leave it out.  (This is another of the dangers of
relying on the header files; it's harder to tell what is a real request
and what isn't.)

> 	<request name="CreatePixmap" opcode="22">
> 		<field type="CARD32" name="screen" />
> 		<field type="CARD32" name="fbconfig" />
> 		<field type="CARD32" name="pixmap" />
> 		<field type="CARD32" name="glxpixmap" />
> 		<field type="CARD32" name="numAttribs" />
> 		<!-- followed by attribute list -->
> 	</request>

In cases like this, where the request contains variable-length data, you
need to actually describe that data in the request.  Use the "list" element.

Note, however, that from a brief look at the GLX wire specification, it
looks like in some cases they may be doing some things with list lengths
based on reply lengths that I haven't added support for in XML-XCB.
I'll try to look into that further.

It's currently possible to have a single list in a reply without a
length expression, and it will then calculate its length from the reply
length.  This won't work if you have multiple lists, and it looks like
GLX has some replies that have both a fixed-length list and a
variable-length list, with the latter taking its length from the reply
length.

For now, if you run into one of those, put a big comment.  I can then
fix it when I change the implicit-length logic.


Again, excellent work!

- Josh Triplett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20050118/0a612f8c/signature.pgp