>> what about the output speed? that *is* for me the main reason to try
>> RASTERCONSOLE, as it claims to speed up this very lame thing (as
>> statet in the kernel config file)...
> Before mouse added the cgsix accelleration RASTERCONSOLE was slower
> than the OBP.

...on the cgsix, yes - I suspect this is because the OBP knows how to
use the cgsix's blitter for scrolling.  RASTERCONSOLE is still a clear
win over the OBP with respect to its effect on interrupt latency, even
when it uses the framebuffer as a dumb memory-mapped framebuffer.

> It's probably still slower on anything other than cgsix.

(Note that most/all of the following is probably more sparc than
sparc64; I don't know which of these framebuffers even exist for
sparc64 machines.)

Well, possibly except the cgthree, which pretty much forces _everyone_
to do dumb-frame-buffer access.

Also, I'm fairly sure I've written acceleration code for at least one
other framebuffer.  I would guess it's the S24 simply because that's
the only other one I have any significant doc on, but I cannot find the
code; maybe I'm confused, or maybe it's on a machine that's down right
now (half my machine room is down while I try to collect the round
tuits to build suitable shelving...).

I do have a cg14 driver that does RASTERCONSOLE in 24bpp mode by
pointing the rcons code at one of the 8bpp equivalent planes, thereby
getting 8bpp speed out of it.  It still isn't as good as the OBP, which
probably knows how to use the acceleration I understand the cg14 has
but which I still have no clue how to use.

/~\ 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