Path: utzoo!attcan!uunet!husc6!paperboy!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!keith
From: keith@EXPO.LCS.MIT.EDU (Keith Packard)
Newsgroups: comp.windows.x
Subject: Re: X11R4 and TrueColor
Message-ID: <9001112228.AA17326@xenon.lcs.mit.edu>
Date: 11 Jan 90 22:28:10 GMT
References: <PINKAS.90Jan11101107@st860.intel.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 25


> I have a dumb framebuffer, with a depth of 16.  The hardware conforms to
> TrueColor/DirectColor model, with a 6-6-4 split for RGB.  (The RBG
> colortables are modifiable, but for right now, I'll settle for static
> colortables.)

The sample server CFB code will work on a 16-bit display.  Porting is
a matter of editing cfbmskbits.c and cfbmskbits.h to conform to the
display characteristics.  You'll need a reasonable understanding of the
contents of those two files to change them appropriately.  The rest
of the porting process will follow a typical CFB server port, several
examples of which are provided with R4.

CFB already supports all possible colormap types, if you're hardware
only supports direct color and true color, you'll simply need to remove
the portions which advertise other visual types to DIX and change the
default visual to either true color or direct color.

Much of the R4 code is tuned for 8-bit displays, but those portions are
carefully ignored in the non 8-bit cases.  Naturally, the performance of
a 16-bit version of CFB will not be stunning; pixel-size independent code
is difficult to optimize.

Keith Packard
MIT X Consortium