From owner-freebsd-hackers Sat Aug 16 20:12:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA27392 for hackers-outgoing; Sat, 16 Aug 1997 20:12:20 -0700 (PDT) Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA27381 for ; Sat, 16 Aug 1997 20:12:16 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by nico.telstra.net (8.6.10/8.6.10) with ESMTP id NAA20381; Sun, 17 Aug 1997 13:11:38 +1000 From: Greg Lehey Received: (grog@localhost) by freebie.lemis.com (8.8.7/8.6.12) id MAA04998; Sun, 17 Aug 1997 12:41:37 +0930 (CST) Message-Id: <199708170311.MAA04998@freebie.lemis.com> Subject: Re: reset screen hardware? In-Reply-To: <199708170301.MAA03401@genesis.atrad.adelaide.edu.au> from Michael Smith at "Aug 17, 97 12:31:55 pm" To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Sun, 17 Aug 1997 12:41:37 +0930 (CST) Cc: hackers@freebsd.org (FreeBSD Hackers) Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by freebie.lemis.com id MAA04998 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id UAA27383 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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