[Xcb] more on the libGL port to XCB

[Jamey Sharp]

These are some observations on libGL and XCB, mostly directed at Jeremy;
but I thought others (especially Josh) might be interested as well, as
we have some things to learn about describing the X protocol still.

GLXSingle requests aren't real X requests. The real requests are
identified by the GLsop ("single opcode") numbers. All of these need to
be described in XCB's GLX protocol description. For example, NewList is
a request with opcode 101 that has no reply; while GetClipPlane has
opcode 113, has a reply with padding to the 32-byte mark, and a double
following that.

Jeremy, you'll need to work out the correct descriptions of these 52
requests, get them into glx.xml, and then make the appropriate
indirect.c functions call those XCB functions directly. I expect the
code will become a lot clearer if you do that.

The GLrop ("render opcode") case, which is much more common, is also
going to need a little bit of work. The current XCB description of
GLXRender won't quite work, because we've never implemented support for
lists of variable-length structures in requests, and RenderCommand is a
variable-length structure. Possibly we should just add support for that;
PolyText8 and PolyText16 in the core protocol have the same problem,
IIRC, and you can see we just kind of kludged around it. The same kludge
will work here, and might be the best choice, at least for now.

List of variable-length structures aside, there's something interesting
about the GLXRender-using code in libGL: it keeps a large buffer around
to write the render commands into, so that it can avoid writing the
8-byte GLXRender request header over and over for each rendering
operation. Well, the core X protocol has some requests where that's a
good idea too, and they're tagged with a combine-adjacent="true"
attribute in the XCB protocol description. If we (if I?) implement
support for actually combining those requests inside of XCB, then libGL
needn't do any buffering of its own. I've been meaning to re-implement
that anyway (it worked a long time ago, but I broke it). So don't bother
using the gc->pc buffer when you implement the GLrop calls, but do add
combine-adjacent="true" to the XML for the Render request.

Hey Josh? I think PolyLine can't have combine-adjacent set. The behavior
of two PolyLine requests is different from that of one request with the
two lists concatenated. I think FreeColors and StoreColors could have it
set, though, and there may be others. ...There's a question in this
paragraph somewhere, but darned if I know what it is.

Having finally reviewed it somewhat, I have some comments on the XCB
description of GLX, for whatever they're worth, which may not be much.
:-)

  * I think the "data" list in RenderCommand should maybe be a list of
    CARD32s, because AFAICT it's always required to be a multiple of
    four bytes long.
  * Context tags and GLX pixmaps need to be declared as XID types.
  * I assume visuals are the standard X type? Then they should be
    VISUALIDs, not CARD32s.
  * Similarly, the font in UseXFont should be of type FONT.
  * Sadly, screens are almost certainly not of type SCREEN, but maybe
    CARD32: type SCREEN is a large structure.
  * QueryExtensionsString looks like maybe it's missing something?

Hope some of that's useful.

--Jamey