Subject: Re: wscons 50 rows
To: Todd Whitesel <firstname.lastname@example.org>
From: Miles Nordin <carton@Ivy.NET>
Date: 01/25/2000 20:35:15
On Tue, 25 Jan 2000, Todd Whitesel wrote:
> I've got quite a few fixed-frequency VGA monitors and they work fine on
> all my NetBSD machines (not just PC's) that support VGA text displays.
Yes, that's a sensical interpretation of fixed-frequency, too. :)
the particular monitor that's plugged into my one PeeCee is a
1600x1280@77Hz page-white IBM monitor that was on eBay a while ago. I
love it--it's absurdly sharp and doesn't seem to need any gamma correction
at all. blah, blah.
> ooh, that sounds like a marvelous evil hack. But of course the
> hardware was never designed to do it, so it's not surprising that it
> didn't work well in practice.
I see what you mean that [svgatextmode] really was kind of clever. I
should be grateful that NetBSD doesn't have to repeat the painful
experiment. You know what's really funny, though--right before I ditched
Linux they implemented the bitmap console I described for a few chips
(Mach64, MGA2164), and they got that wrong, too! The code did not program
the chip as advertised. I had a modeline that worked in XFree86, but got
me horizontal sync/no vertical sync under their matroxfb driver. I could
see that nefarious little greyscale penguin bootlogo gratuitously flipping
top-to-bottom, but it was still clearly square and stayed on the
right-hand side--just enough workingness to be frustrating.
On Tue, 25 Jan 2000, R. C. Dowdeswell wrote:
> this approach doesn't answer at all the question of the boot blocks,
> which would not produce visible output.
It might actually be worse than that. My Sun's continue using OpenPROM
for output until the framebuffer attach, which happens fairly late in the
boot process (although, still before things like the ``root on?'' prompt).
Much of the kernel boot info might render too late for said info to
usefully diagnose panics or freezes. But, it's better than nothing, and
might be the best that can be done under the circumstances.
if such bitmap stuff ever happens it makes more sense that someone who
actually needs the bitmap-on-VGAish chip support will do it, and then it
can someday be backported to the PeeCee with minimal effort. It looks to
me like (cough, matroxfb...caugh, cough) when people write code they
don't actually need, they tend to get it wrong. :)
For example, on the alpha port it might be needed, as there is no
proven-good way to initialize an arbitrary chip--Digital tries to do it by
running the x86 VGA BIOS under emulation. When/if XF86-4.0 inspires VGA
console support on the alpha, the lucky implementor may find himself or
herself convinced it's better to support a limited subset of chips by
direct programming than to rely on the srm console's hit-or-miss x86
emulation that's as likely to lock a box hard as actually initialize the
card. (i'm a bit _beyond_ convinced of this, personally. frankly i think
even a meager effort would improve the number of cards that work over what
srm provides.) in which case, the bitmap console would end up being less
work since the Sane Framebuffer Architecture uses it anyway.
i guess we'll see, and my IBM monitor under X/serial console is working
fine in the mean time.
Miles Nordin / v:+1 720 841-8308 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US