Messages in this thread |  | | | Date | Sat, 13 Dec 1997 15:36:30 -0700 (MST) | | From | teunis <> | | Subject | Re: Console handling (was: Re: Let's vote for PnP on 2.2) |
| |
On 10 Dec 1997, H. Peter Anvin wrote:
> Followup to: <199712100251.VAA15925@jupiter.cs.uml.edu> > By author: "Albert D. Cahalan" <acahalan@cs.uml.edu> > In newsgroup: linux.dev.kernel > > > > > 1. Make the kernel know how to reset the video card to a known state. > > > > You can go from a known state to a known state. > > You can go from any state to an unknown state -- useless. > > Sorry, you can't get to a known state from an unknown state. > > > > Sure you can. It's pretty common to do so. In fact, whenever you > initialize hardware, this is usually exactly what you do.
That's what makes coding a driver for a secondary video card fun... [BTW - Matrox's cards are nice about this AFAIK].
For the S3 cards you have to know: How much videoram you have, how fast the videoram is (ram-timing) and what other timings are needed for that particular manufacturer's card... BTW : this info is generally not all that easy to get.... [though iirc most videoram is of common speed] system BIOS knows how to tell video BIOS to initialize a videocard. This is not true for secondary videocards... and asking the BIOS to initialize those cards would crash as they'd want to be in VGA-mode.
Now I realize that not alot of people out there play with multiple videocards.... so for them this point is moot. [it's _VERY_ handy for CAD and VR though :] Does this help explain some of it? (I won't bother anyone about this on this list for another few months... I don't really have anything more to offer for info.. personally even though I'm trying to work on GGI I haven't yet been sold on why it's better than doing a usermode daemon - beyond the DMA and IRQ-related stuff that is. Though libGGI is very handy as it'll run on X as well as GGI/KGI [and soon svgalib I hope] without recompilation :).
G'day, eh? :) - Teunis
|  |