Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Questions about visuals on 16 bit/pixel
Message-ID: <9005052221.AA00329@expire.lcs.mit.edu>
Date: 5 May 90 22:21:45 GMT
References: <PINKAS.90May4131220@st860.intel.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 25


    This is fine for TrueColor and
    DirectColor, which pass the size of the largest colormap (R, G, or B).  In
    our case, this is 64.  However, for StaticColor, this would be 2^16, which
    cannot be represented in a CARD16.

Just don't export StaticColor (it really isn't very useful, once you
export TrueColor).  Otherwise say the size is 65535, and throw away a value.
The sample server implements all of the visuals primarily as a mechanism
for testing clients against the various visuals, not because they are all
useful on an 8-bit display.

    It is interesting to note that in the VisualInfo structure, colormap_size
    is declared as an int.

That's a general Xlibism.  In the protocol it's CARD16.  We probably should
have made it CARD32 to handle this case, but we didn't.

    We also wanted to provide PseudoColor, GrayScale, and StaticGray visual.
    From what I could determine, we would only be able to implement these at a
    depth of 4, due to the fact that there are only 4 bits in the blue
    colormap.

I suspect you don't really mean "depth" of 4, you mean a colormap size of 16.
Yes, I believe that's what you have to do.