Subject: Re: SPARCstation SLC/ELC
To: None <port-sparc@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-sparc
Date: 02/25/2002 17:59:50
>>> [...]
>> Of course, if you do that you're stuck with the ROM console font, at
>> 80x34 to boot.
> Yes, and...?

And some people - like me - prefer otherwise.  Most of my consoles do
192x69 (FONT_FIXED6x13 and RASTERCONS_FULLSCREEN on 1152x900); until I
moved console to the color head, sparkle did, IIRC, 266x98 (same
options on 1600x1280).  And I prefer them that way, or I'd've gone back
to FONT_GALLANT12x22 and/or no RASTERCONS_FULLSCREEN.

>>> Of course, RASTERCONSOLE works, too -- only the cg6 seems to really
>>> suffer from RASTERCONSOLE being in there, if I recall correctly...
>> The cg6 _doesn't_ suffer; that's what all the cg6_ras_ stuff in
>> dev/sun/cgsix.c is for.
> If it hasn't changed in, say, the last two years, then the cg6
> RASTERCONSOLE reeks in comparison to the fastcons hack.

I don't recall trying fastcons.  Perhaps RASTERCONSOLE is slower.  (I
wonder if using the cg6's font-drawing support would help matters any.)

> Last I checked, scrolling on a cg6 didn't work too well with
> RASTERCONSOLE -- it was very choppy.

I've always - well, ever since I added the cg6 acceleration support for
scrolling - found it beautifully smooth.  (Not smooth as in VT100-style
smooth-scroll, smooth as in nothing I would describe as "choppy".)

>> Of course, anything that uses the cg6 acceleration for console
>> output - whether via the ROM code or via RASTERCONSOLE - is liable
>> to do unpleasant things if it prints anything when you're running
>> anything else that uses the cg6 acceleration hardware.
> I don't see any other issues besides the obvious "Console output
> scribbles on X session..."

I didn't say X.  I haven't had trouble with X; I speculate that it's
because the X server resets all relevant registers before each
operation using the acceleration hardware.  But some programs, programs
that set up the hardware and assume it stays set up, work fine until
console output occurs, at which point they start misbehaving
catastrohpically.  (I have a wire-frame animation program that switches
from smooth animation to an ugly mode where it toggles between
white-on-black and black-on-white with every frame drawn, which amounts
to the whole screen flashing at typically about 20Hz.)

Depending on your philosophy, this is either

(a) RASTERCONSOLE's fault, for not saving and restoring hardware state;
(b) the userland programs' fault, for assuming nothing else will meddle
    with the hardware; or
(c) pilot error, running a program that makes the assumptions mentioned
    in (b) on a cg6 that's also the destination for console output.

And, of course, the Right Fix depends on which view you take.

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