From owner-freebsd-hackers  Thu Aug 14 22:30:55 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id WAA09111
          for hackers-outgoing; Thu, 14 Aug 1997 22:30:55 -0700 (PDT)
Received: from suntan.tandem.com (suntan.tandem.com [192.216.221.8])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA09097
          for <hackers@freebsd.org>; Thu, 14 Aug 1997 22:30:53 -0700 (PDT)
From: grog@lemis.com
Received: from papillon.lemis.com by suntan.tandem.com (8.6.12/suntan5.970212) 
	id WAA13971; Thu, 14 Aug 1997 22:30:45 -0700
Received: (grog@localhost) by papillon.lemis.com (8.8.4/8.6.12) 
       id RAA00646; Thu, 14 Aug 1997 17:37:38 +0900 (JST)
Message-Id: <199708140837.RAA00646@papillon.lemis.com>
Subject: Re: reset screen hardware?
In-Reply-To: <199708130318.MAA11651@genesis.atrad.adelaide.edu.au> from Michael Smith at "Aug 13, 97 12:48:19 pm"
To: msmith@atrad.adelaide.edu.au (Michael Smith)
Date: Thu, 14 Aug 1997 17:37:34 +0900 (JST)
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=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Michael Smith writes:
> Alfred Perlstein stands accused of saying:
>> I'm not familiar with the protection mechanism in freebsd, if i wrote a
>> program to reset the text screens by programming the ports what kind of
>> skeleton code would it need?
>
> It wouldn't work.

Why not?  The X server does just that.  Sure, before it starts, it
does a lot of checking, but that's relatively recent.  Just a few
years ago, you had to tell the X server what your board was.  And if
you were wrong, to quote you:

> You would, in fact, stand a reasonable chance of producing a program
> which would be able to destroy utterly older monitors and many LCD
> panels.

Yes, you're right about the consequences.  But your conclusions are
wrong.  This is, in other words, an argument why X can't work on PCs.

>> Btw, there are interupts that point to tables of data that is put into
>> the videocard to set various modes, could the kernel save the data before
>> it switches to protected mode?
>
> Different cards have different register sets.  There is no structure
> in a video card BIOS that describes the data and the registers in such
> a fashion that you can manipulate them without first knowing what the
> card is.

Yes, of course, of course, and we've all been through this dozens of
times before.  Having to tell your system what kind of board(s) it has
stinks, but IMO it's still better than having a panic and not being
able to enter the debugger because the bugger is still in graphics
mode.

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.

Greg