Date: Sun, 17 Aug 1997 12:31:55 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: grog@lemis.com (Greg Lehey) Cc: sos@sos.freebsd.dk, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: reset screen hardware? Message-ID: <199708170301.MAA03401@genesis.atrad.adelaide.edu.au> In-Reply-To: <19970817113251.14722@lemis.com> from Greg Lehey at "Aug 17, 97 11:32:51 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey stands accused of saying: > > > > I can be done, sure, but it will NEVER get into the official kernel > > like that, I'll fight that tooth and nail. > > How about a more positive approach? I know plenty of people who'll > tell me in vivid detail why things won't work. This is like asking for a positive approach to a VMS ABI emulation module 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. > > There is hope however, there is work underways to do this via the > > video BIOS, and that's a totally different story... > > Do tell. Check Jonathan Lemon's recent post wrt. calling the BIOS from the kernel. > I think we're mixing up different problems here. Let's try to > separate them: > > 1. When the system or the X server crashes, there's no way to get the > display back to normal. We need to fix that, and I don't think > anybody really disagrees with this one. More specifically, we need some functionality to restore the display hardware from some arbitrary state to a known, usable state. It doesn't matter _why_ we want this. > 2. Is it possible? Some people say no. But the X server does it > when it stops normally, so it *is* possible. All things are "possible". I don't think there's any argument about this. "Feasible" is the term under question. > 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øren that kernel bloat is Bad. Call the BIOS on the video card. See above. > How about a routine that runs from /etc/rc, does the probing, and > saves it in kernel data via an ioctl? Then we have another ioctl to > reset the state. I'd guess that there aren't more than 20 or 30 > registers to restore, each only a byte wide, so we're not talking huge > quantities of data. Hah. You obviously haven't had to work with PC viode hardware, have you? Add these to your list of things to deal with : - write-only registers - programming-order-dependant operations Basically, it is not possible to take a snapshot of the state of a modern video adapter without uintimate knowledge of the hardware involved. Such a snapshot is often useless anyway, as it does not contain information about the state transitions prior to the snaphot state, which may be very significant to the hardware's current mode of operation. 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? > Greg -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708170301.MAA03401>