> I'm seeing some unusual behavior in my attempt to get a 24-bit
> framebuffer working.  Here's what I've seen so far:

> 1) A simple userland program I've written is successfully able to
> mmap the display and scribble graphics.  This program has no problem
> painting over the entire 1152 x 900 pixel area.

Yay!

> 2) Xsun24 starts up okay, but segfaults after attempting to paint the
> background stipple pattern.  Actually, it gets about 7/8 of the way
> down the screen, before crashing at a reproducible spot halfway
> through one particular horizontal scan line.

This sounds as though maybe the server is mapping less than it should.
Did the userland program in (1) get the size-to-mmap from the same
place the server does, or did you just hardwire that knowledge?  I'm
thinking maybe the size you're returning is smaller than it should be.
Perhaps you're telling userland it's 3110400 bytes big instead of
4147200 bytes big, and it's crashing at 3110400 plus enough to round up
to some sort of MMU boundary?

This is vaguely reminiscent of something that happened to me yesterday.
I had a large file - some hundreds of megabytes - and when I tried to
use mmap()-based programs like tail(1) or my own mcgrep(1) on it, they
crashed, as if there were effectively a silently-enforced maximum size
on an mmap()ed region.  I doubt this is your problem, though, because
(a) you're nowhere near hundreds of megabytes, (b) my problem struck on
a very old OS (1.2something), and (c) your "test" userland program
works fine.

> Oh, and one other question: If I comment out the bad function call
> mentioned above, I can get a working X desktop -- as long as nothing
> I run comes near that magical 7/8 boundary.  But the colors are
> strange.  xterms come up in purple.  No big deal, but apparently some
> initialization code needs to set up colors properly, even in
> TrueColor mode.  Can anybody give me any pointers on this, especially
> since all the existing video drivers are 8-bit only?

All three primaries work correctly in your small test-scribbling
program, I take it, so it's not the hardware?  Perhaps the pixel fields
are wrong, and the green primary got switched with the spare byte?  Or
is the hardware really three addresses per pixel instead of four?  (All
the above assumes it's four bytes per pixel as far as addressing goes.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B