Date: Sun, 17 Aug 1997 11:32:51 +0930 From: Greg Lehey <grog@lemis.com> To: =?iso-8859-1?Q?S=F8ren_Schmidt?= <sos@sos.freebsd.dk> Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: reset screen hardware? Message-ID: <19970817113251.14722@lemis.com> 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_%2B0200?= References: <199708140837.RAA00646@papillon.lemis.com> <199708150627.IAA17998@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970817113251.14722>