From owner-freebsd-hackers Sat Aug 16 19:04:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA24280 for hackers-outgoing; Sat, 16 Aug 1997 19:04:07 -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 TAA24257 for ; Sat, 16 Aug 1997 19:04:01 -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 MAA14340; Sun, 17 Aug 1997 12:02:54 +1000 Received: (grog@localhost) by freebie.lemis.com (8.8.7/8.6.12) id LAA04500; Sun, 17 Aug 1997 11:32:51 +0930 (CST) Message-ID: <19970817113251.14722@lemis.com> Date: Sun, 17 Aug 1997 11:32:51 +0930 From: Greg Lehey To: =?iso-8859-1?Q?S=F8ren_Schmidt?= Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: reset screen hardware? References: <199708140837.RAA00646@papillon.lemis.com> <199708150627.IAA17998@sos.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.81e In-Reply-To: =?iso-8859-1?Q?=3C199708150627=2EIAA17998=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Fri=2C_Aug_15=2C_1997_at_08=3A27=3A1?= =?iso-8859-1?Q?3AM_+0200?= 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-MIME-Autoconverted: from 8bit to quoted-printable by freebie.lemis.com id LAA04500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id TAA24274 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Aug 15, 1997 at 08:27:13AM +0200, Søren Schmidt wrote: > In reply to grog@lemis.com who wrote: >> >> Alfred: Mike's right. It's a pain, and also a can of worms. But he's >> wrong when he says it can't be done. If you want to do yourself and >> everybody else a service, investigate the probe and reset code in >> XFree86 and figure out how to cannibalize it to save the board state >> (it makes sense to have this done during boot at probe time) and >> create an ioctl to use this information to reset to text mode. > > 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. > 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? > There is hope however, there is work underways to do this via the > video BIOS, and that's a totally different story... Do tell. 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. 2. Is it possible? Some people say no. But the X server does it when it stops normally, so it *is* possible. 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. 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. Greg