
GLX 1.3 documentation
---------------------

Prior to 1.3, specifying GLX_RGBA attribute to glXChooseVisual
guaranteed a true (or direct) color visual would be selected, and not
specifying GLX_RGBA guaranteed a pseudo (or static) color visual.
This is no longer true in GLX 1.3 which supports a fancier notion of
GLXFBConfigs.  Mesa is also happy with RGBA in pseudocolor visuals.

Colormaps and associated behavior are not specified in the standard.

GLXDrawable is union of GLXWindow, GLXPixmap, GLXPbuffer, Window
  (Pbuffer is like Pixmap, but not assocated with any X Drawable)
  -- note X's Window is included in this list,
     this is how Mesa works, and apparently pre-1.3 GLX

------------------------------------------------------------------------
Notes gleaned from Mesa implementation:
---------------------------------------

The colormap may be inherited from the parent, or a private map for
the window can be created (informing the window manager by a property
on its toplevel that the map should be installed).  Mesa will go ahead
and allocate its own colors in this colormap, in either case.  When
the colormap is exhausted, it moves on to a "closest" RGB algorithm in
the colormap.

Note that Mesa uses XGetWindowAttributes to return the colormap.  If
O'Reilly is right, this defaults to CopyFromParent (i.e.- 0), which it
looks like Mesa would decide to allocate its own.  Hence the colormap
attribute should actually be set on the Mesa window, even if only to
the default colormap.

The colors Mesa attempts to allocate are determined by the DITHER666
macro at (Mesa) compile time -- if set, it tries to get a 6x6x6 RGB
cube; by default Mesa takes a 5x9x5 RGB cube.  Apparently, neither
OpenGL nor GLX provides any way to tell anything about how colors are
handled.  Mesa defines the symbol MESA, but nothing in its published
headers (xmesaP.h is the unpublished header) tells how DITHER666 was
set at compile time.  Note says 5x9x5 better for general colors, 6x6x6
better for grayscale (but why would you dither grayscale??).  The
5x9x5 appears to be the default.

     xcol.red  =gamma_adjust(v->RedGamma,   r*65535/(_R-1),65535);
     xcol.green=gamma_adjust(v->GreenGamma, g*65535/(_G-1),65535);
     xcol.blue =gamma_adjust(v->BlueGamma,  b*65535/(_B-1),65535);
     noFaultXAllocColor(v->display, cmap,
			v->visinfo->colormap_size, &xcol, &exact,
			&alloced);

(Note that Mesa allocates these in order, which means that when the
table fills up, all the colors it's missing lie at one end.)

/*
 * Apply gamma correction to an intensity value in [0..max].  Return the
 * new intensity value.
 */
static GLint gamma_adjust( GLfloat gamma, GLint value, GLint max )
{
   double x = (double) value / (double) max;
   return (GLint) ((GLfloat) max * pow( x, 1.0F/gamma ) );
}

Where gamma (defaults to 1.0) is separately set for RGB in the
MESA_GAMMA environment variable.

My guess in general is that OpenGL is not going to work very well
unless the X server has true color.  In pseudocolor, there is no way
to make GLX work together with any other clients.  In particular, it
is apparently impossible to figure out what colors a GL window has
allocated in order to use them in non-GL windows.

The best color policy is probably to allocate a few colors -- the
standard colors -- in the colormap before giving the window to GL.
Note that the 8 standard colors are always on the list requested by
Mesa's cubes, so Mesa will need either 217 or 208 colors to get its
full set.  In practice, if you were using Mesa, you could easily
allocate the identical colormap for your own use, in effect reusing
Mesa's colors.
