> How does it die?


Well, it no longer dies.  Xsun24 had some hardwired assumptions about
the cgeight built into it, so it was adding its own mmap offset of
0x40000 on top of the memory map offsetting I was already doing in my
driver.  When I commented that out, the display worked fine.

[I had to shudder when I saw this in Xsun24:

   #define CG8_COLOR_OFFSET 0x40000

Why can't this stuff just be done in the driver?]

Which leads me ask a general question to the NetBSD community: how
should we handle Xsun24?  Knowing what I know now, it's relatively
trivial to bring up new 24-bit adapters, but Xsun24's hardwired
assumptions are going to be a real pain in the butt.  I'm currently
going through the pixel-packing routines, looking to generalize them to
support the "little endian" *and* inverse masked pixel ordering my
hardware requires (see a previous message).  In the process, Xsun24 is
probably going to become a whole new piece of code.  Do the X11 folks
want to maintain this?  Or are we going to have our own little variant
of X11 to maintain?  Does anyone care?

BTW, I'm thinking of modifying the kernel fb structures to support
fields like the following:

char *fb_pixelOrder = "RrGgBb";  
int fb_pixelXORMask = 0x00; 

Where R = red MSB, r = red LSB, G = green MSB, etc.  These (or something
similar) should help the generalization process.  My oddball hardware
could thus compactly be described as:

char *fb_pixelOrder = "bBgGrR"
int fb_pixelXORMask = 0xFFFFFF;

Or whatever.

-David.