A while back I wrote about what X11's TrueColor means. In comments Aristotle Pagaltzis and I wound up getting into the fun world of X11 visual types, especially the DirectColor visual type, which has an indexed colormap like PseudoColor but with the R, G, and B channels indexed separately. As a result of this I wound up with two questions: where did DirectColor come from, and was there ever any hardware that actually had real DirectColor support? Today I'm mostly going to tackle the first question.

(If you look at xdpyinfo output on your modern 24-bit TrueColor display you'll almost certainly find a whole collection of 24-bit DirectColor visuals. I'm pretty sure that these are implemented in software, not hardware, although I could be wrong.)

Old versions of both X10 and X11 are available through x.org's archive, so we can go digging. The obvious place to start is investigating the last version of X10, X10 R4, and what its colour models were. Well, colour model, as it turns out; X10 apparently had only a version of what X11 calls PseudoColor. However, this version is somewhat different. Quoting from doc/Xlib/ch08a.t in the tarball:

The red, green and blue values are scaled between 0 and 65535; that is `on full' in a color is a value of 65535 independent of the number of bit planes of the display. Half brightness in a color would be a value of 32767, and off of 0. This representation gives uniform results for color values across displays with different number of bit planes.

I was going to say that this is different from X11, but it's actually not. At the protocol level X11 continued to use this scaled spectrum of colour values, although it will tell you how many bits there actually are in each RGB value.

X10 has no specific colormaps for greyscale displays, but notes:

On a multiplane display with a black and white monitor (greyscale, but not color), these values may be combined or not combined to determine the brightness on the screen.

Given the mention of a black & white monitor here, X10 is probably contemplating a situation where people connected a b&w monitor to a machine with colour graphics. Such a monitor might be driven from only a single colour channel, for example green; this was easy back in the days when each of R, G, and B might use a separate physical connector (usually BNC; this persisted into the VGA era).

The first version of X11 was of course X11 R1. It has the same six visual types that modern X11 (nominally) has; StaticGrey, StaticColor, TrueColor, GrayScale, PseudoColor, and DirectColor. For GrayScale, the protocol specification now notes:

GrayScale is treated the same as PseudoColor, except which primary drives the screen is undefined, so the client should always store the same value for red, green, and blue in colormaps.

(The protocol specification also notes that 'StaticGray with a two-entry colormap can be thought of as "monochrome"'.)

According to the X.org history page, X10R4 was released around the end of 1986 and X11R1 followed in September of 1987. One of the purposes of the X10 to X11 shift was to do a more hardware neutral and thus generalized redesign (see eg Wikipedia), so it's not really surprising to me that one part of that was taking a very simple and relatively limited colour model and generalizing it wildly. The X11R1 Xlib documentation already has the breakdown diagram in X11 visual types, and I suspect that the orthogonality on display was deliberate, even if at the time no one was sure if the capability would ever appear in actual hardware. Since X11 was defining a protocol for the long term, being general made a lot of sense; better to over-generalize when creating the protocol then never use some capabilities rather than under-generalize and have to try to figure out how to extend it later.

(As it turns out, X didn't get this perfect since all colours are in RGB. Modern hardware often also supports things like YUV colour.)

X11 R1 doesn't seem to contain code for any hardware that supports DirectColor. While hardware code under server/ mentions it, it's always to report errors if you try to actually use DirectColor visuals. It's possible that the device independent code was capable of faking DirectColor on PseudoColor or TrueColor visuals, but I'm not sure.

(Investigation of other versions of X11 will be deferred to another entry, since this one is already long enough.)