> > but the X server coredumps when the driver is emulating a cgeight,
> > and it dumps core before even mmaping the display.
> 
> I guess it is not surprising, the cg8 does not look like a cg14 at all
> (unless I am missing something here): The color setup is very
> different, and the mdi has only three modes: 8bpp, 16bpp and 32bpp
> (this one is the one you can actually drive in 24 bit mode by careful
> setup of the X lookup table and careful use of that table on the X
> plane).  Mhm, probably you are using the chunky mappings, that would
> be a close approximation?  In any case, you still need to get the
> color right for the mdi.

Yeah. I've had it displaying a 24-bit splash screen for about three weeks
now, but it is only because I write it directly to the VRAM :-) It does
this in 24-bit (actually 32-bit) chunky BGR (or XBGR) when the Xlut is 
correctly initialized.

I know very little about the cg8, but from the barebones netbsd driver,
it seems that it is a dumb 24-bit FB, and all it takes is to convert the
mmap addresses to make the cg14 look like it (same procedure as emulating
the cg3). But this doesn't work for some reason. Like I said, X dumps
core before it even starts to touch the frame buffer memory. I'm not even
sure that the endianness of the RGB pixels will match with the cg8/cg14;
I just wanted to get something on the screen as proof of concept that
the cg8 emulation would work. But some function in the X server gets
a null pointer, so it crashes; I haven't gone further than that since
a gcc -g version of Xsun24 is too big for the crufty gdb that NetBSD
uses, at least without a kernel tweak to increase the max data size.
This is a very back-burner project, so I haven't bothered to try to
understand the spaghetti inside Xserver.

To those reading port-sparc: Is having the cg14 driver (even in 8-bit mode)
in the post-1.2 tree something people would like to see now? I can commit
it relatively soon with the 24-bit stuff ifdef'd out if there is demand
for it...

--Aaron