Date: Mon, 18 Aug 1997 13:04:02 +0930 From: Greg Lehey <grog@lemis.com> To: Terry Lambert <terry@lambert.org> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, sos@sos.freebsd.dk, hackers@FreeBSD.ORG Subject: Re: reset screen hardware? Message-ID: <19970818130402.63952@lemis.com> In-Reply-To: <199708171933.MAA07196@phaeton.artisoft.com>; from Terry Lambert on Sun, Aug 17, 1997 at 12:33:21PM -0700 References: <199708170301.MAA03401@genesis.atrad.adelaide.edu.au> <199708171933.MAA07196@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 17, 1997 at 12:33:21PM -0700, Terry Lambert wrote: >>>> 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. Yup. >>> 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. Are you sure of this? Most BIOSes manage to reset to text mode every time you reboot the machine, even without a hardware reset. But in general I agree, this is a bit of a kludge. >> ... ] > >> 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). No, it wasn't naïve. You appear to have misinterpreted it. Sure, there's more to it than just supplying a list of register/content pairs, but not too much more. An appropriately intelligent format of the register list would handle it. >> 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). There's another point to be made that the board manufacturer's software doesn't do all the things we would like to do with it. It's optimized for Microslop, and even Microslop environments need external drivers. Sure, as I suggested in an earlier message, we can follow up the BIOS calls with appropriate calls from the video driver. And it would probably work. But it's not pretty. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970818130402.63952>