pinkas@st860.intel.com (Israel Pinkas) (05/05/90)
We are porting X11R4 to a 16 bit/pixel framebuffer that follows the
DirectColor model. (Pixels are divided into RGB as 6 bits R, 6 bits G, and
4 bits B.) At present, we have implemented TrueColor and are working on
the other 5 visual classes. We need some information in order to proceed.
In server/ddx/cfb/cfbscrinit.c, there is a table that defines the visual
classes supported by the server. We currently have the following:
#define PSZ 16
#define _BP 6 /* number of bits in one DAC component */
#define _RZ 6
#define _RS 10
#define _RM 0xfc00
#define _GZ 6
#define _GS 4
#define _GM 0x03f0
#define _BZ 4
#define _BS 0
#define _BM 0x000f
#define _CE (1 << _RZ) /* 64 */
static VisualRec visuals[] = {
/* vid class bpRGB cmpE nplan rMsk gMsk bMsk oRed oGrn oBlue */
0, TrueColor, _BP, _CE, PSZ, _RM, _GM, _BM, _RS, _GS, _BS,
0, DirectColor, _BP, _CE, PSZ, _RM, _GM, _BM, _RS, _GS, _BS,
}
When we decided to implement the other Visual types, we ran into some
problems. We thought that we would be able to support a StaticColor visual
that had 16 bits/pixel (basically the same as TrueColor). The problem is
that when the connection is made to the server, the colormap size is passed
back as a CARD16 (red book, page 360). 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.
It is interesting to note that in the VisualInfo structure, colormap_size
is declared as an int.
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. (If I go larger, changing Pixel 0 will change the Blue for 16,
32, etc on a PseudoColor visual. On the Gray visuals, a similar limitation
applies if we want to keep the 3 guns firing at the same intensity.)
I would appreciate hearing from anyone that has implemented StaticColor at
a depth of 16 to see how they overcame the problem in the Protocol.
-Israel Pinkas
pinkas@st860
--
--------------------------------------
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation. In no way should the above be taken
to be a statement of Intel.
UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas
ARPA: pinkas%cadev4.intel.com@relay.cs.net
CSNET: pinkas@cadev4.intel.comrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (05/06/90)
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.