Arguably, doing that as an X-only thing might be the way to go; you really
	don't want to be storing 8x1152x900 bits per screen for the consoles,
	never mind 24x1280x1024!

	I wonder if it would warrant a flag bit saying "preserve this console as
	a bitmap" somewhere, and it would preserve the others as character cell
	arrays...

Uh, 1MB (for 8x1152x900) wired kernel memory just to store a 
backup bitmap image?  ``Just say "No."''

	Dare I state that Linux managed to do the wscons stuff properly (for some
	value of proper -- it worked for me when I was running the Ultra port
	with a Creator3D card on an Ultra 1 -- which, barring a SCSI card, I
	would take over an Ultra 5/10 any day of the week...).  I know this
	isn't Linux (thank the Gods for large favours!), but there's obviously
	something they managed to implement correctly.  I don't see too terribly
	much impeding us from doing the same.  Perhaps we're not initializing
	the palette correctly (at least on the CG6)?

What's the matter with cgsix?  Works fine for me.  Just like
sunos.  I don't like the way linux switches from the PROM to
their internal console and lose all the PROM messages.

	If someone wants to send me a 13W3-M/VGA-F adapter, I can poke my nose
	into at least the cg6 RASTERCONSOLE stuff and see if I can at least
	get the ANSI colour stuff working.  wscons might be a bit trickier.

RASTERCONSOLE.  Ick.  Tried it.  Didn't like it.  

(If you think you have performance issues with the console,
RASTERCONSOLE won't help much.  Remember, to scroll the
console requires moving 1MB of memory.  That memory is mapped
in 8KB at a time, so you will take a minimum of 128 TLB faults.
Since the TLB only holds 64 entries, this requires two complete
flushes of the DTLB, and then some.  This causes performance issues
not only for the rendering, but also flushes out any of your user
or kernel TLB entries as well.  

I considered mapping the frame buffer with a single giant page, 
but the current mmap() interface does not lend itself to that.)

Eduardo