On Sat, 2 Jun 2001, der Mouse wrote:

# > Now the REAL boon would be getting wscons functionality into those
# > ports which use framebuffers, although admittedly that'd be
# > potentially more space used (but not if you only stored text and did
# > a remap instead of doing something completely boneheaded like storing
# > the bitmaps :-).
#
# I've considered doing console switching *with* just storing the
# bitmaps, for bitmap framebuffers; in particular I've wanted to be able
# to switch away from an X session, which would mean doing interesting
# things with mmap...a while ago, I did similar hacks in the X server,
# but that would be X-only.

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...

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)?

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.

# /~\ The ASCII				der Mouse
# \ / Ribbon Campaign
#  X  Against HTML	       mouse@rodents.montreal.qc.ca
# / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
#


				--*greywolf;
--
NetBSD: Are you old enough to run it?