Date: Sun, 17 Aug 1997 12:41:37 +0930 (CST) From: Greg Lehey <grog@lemis.com> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: hackers@freebsd.org (FreeBSD Hackers) Subject: Re: reset screen hardware? Message-ID: <199708170311.MAA04998@freebie.lemis.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
Michael Smith writes: > 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) Yes. If people want it. I didn't say it had to be nice. -- rant mode on -- If there's one thing that pisses me off about many FreeBSD hackers, it's this attitude "Ooh, this is nasty. I don't want to have anything to do with it". Lots of PC hardware is nasty. Messing around in a 16 bit BIOS is nasty. IDE is nasty. VGA is nasty. Come to think of it, what's nice about PC hardware? But FreeBSD's acceptance suffers significantly because nobody can be bothered to deal with these nasty things. Where's the Win-32 emulator? ... -- rant mode off -- >>> 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. Must I? I took a look at SuperProbe. The binary is 83 kB, and in the kernel some of that could go. Sure, that's too much for the kernel, too, but it's still not hundreds. >>> 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 seem to have missed that one. Can you resend it to me? >>> 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. Fair enough. >> 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. Will do. >> 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? No, but I've worked with PC video hardware. It's not that tough. > Add these to your list of things to deal with : > > - write-only registers > - programming-order-dependant operations Yup. But you can deal with that in the probe routine and with a specific structure definition. > 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. But we still have the evidence that every X server manages to reset them most of the time. > 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? OK, as I said, I haven't read Jonathan's message. I didn't realise it was that close to being implementable. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708170311.MAA04998>