Date: Sun, 17 Aug 1997 12:33:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: grog@lemis.com, sos@sos.freebsd.dk, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: reset screen hardware? Message-ID: <199708171933.MAA07196@phaeton.artisoft.com> In-Reply-To: <199708170301.MAA03401@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Aug 17, 97 12:31:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> This is like asking for a positive approach to a VMS ABI emulation > module 8) hahahahahahaha! 8-) 8-). > > > We wont have hundreds of K's of code like that in kernel space. > > > > That's for sure. But who says it'll be hundreds of Ks? > > Have a look at the X server sources someday. But be sure to only look at the DDX code for the generic VGA, since that's the only thing that will be there by default in any sane design. Basically, something that has to be there anyway, if we ever go for more Linux support. The difference is the libvga stuff in Linux isn't used by their X server, so it's redundant code. 8-). > > 3. How to we implement it? Ah, there's the rub. I still think it > > belongs in the probe routines when the system starts up, but on > > the other hand I agree with S=F8ren that kernel bloat is Bad. > > Call the BIOS on the video card. See above. This won't necessarily result in the card going from some arbitrary state to some known state, unless the BIOS was used to get the card into that state in the first place. Specifically, there exist write-only registers which are shadowed in RAM on a number of cards, and any modification outside the BIOS will result in the shadow data being rendered stale. Any attempt to restore the card toa known state using BIOS will only operate on the deltas from the shadow state to the desired state. Unless you modify X to use the BIOS calls to set the card state, you will not be able to use the BIOS to reset the card state. Further, it's probably desirable to link the state restoration to the *previous* state, which may not be known to the console driver, rather than the default state (which might be). For example, consider a 50 line text display following the manual loading of a VGA font for support of this mode, the memory for which is subsequently stomped by the X server. Consider also the possible consequences of a previous mode that was not the default mode for the kernel debugger in a break to kernel debugger while X is active on the console. If a BIOS-based approach is used, it will seriously limit the available modes for normal console operation and for X servers; this is probably an unacceptable consequence. [ ... ] > Hah. You obviously haven't had to work with PC viode hardware, have you? I agree with this "hah"... that last suggestion was naieve. On the other hand, I don't think it was punishably so, I think he was just trying to compromise with an uncompromising opponent. 8-) 8). > On the other hand, the manufacturer of the card _does_ know intimately > how it works. They write functions for manipulating the card > hardware, and stick them in a PROM on the card. > > Why not use their code and save ourselves the agony? Because unless you use their code for all things, the result of using their code is indeterminate. Even if the automaton involved is determinant (it is), the results depend entirely on the start states (they aren't). It's like running Conway's "Life" in hardware. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708171933.MAA07196>