> This does not look very good.  It's been a while since I worked on X
> servers and frame buffers, but I believe that the X server needs to
> know what size the framebuffer is.  I think this information is
> gathered through the FBIOGATTR ioctl().  Part of the information
> returned is encoded in fbtype structures, which have the framebuffer
> size in them.  You should make sure you're returning correct
> information for the FBIOGATTR calls.


Kudos to Eduardo on this one.  Sure enough, I did not realize there was
a fb_size field, which tells Xsun24 how much memory to mmap.  (What? 
You mean if I give it the height, width, and depth, it can't figure it
out for itself?  :-)

So once I fix that little boo-boo, I come to this show-stopper:

   Async registers (mid 0): afsr=1000<UC,AFA=0>; afva=0x00
   NMI: system interrupts: 20080000<VME=0,SBUS=0,T,I>
   sbus error:
           AFSR a188020e<PAH=e,SSIZ=1,SA=0,FAV,MID=0,S,SIZ=0,TO,ERR>
           address: 0xe0

These repeat for a while, with the data changing each time, until the
machine says "too many sbus errors" and tries to panic.  From my printf
debug statements, it's clear that Xsun24 mmaps the entire 4MB
framebuffer just before all this happens.

So I guess my mmap routine isn't working right.  

Any pointers on the direction to take from here?  If there's some
consistency in how these 4MB frame buffers should be handled, I'd be
happy to try to create a more general 'truecolor0' device, with support
for things like Mr. Brownlee's cg12s...

-David.