From owner-freebsd-hackers Fri Aug 8 17:48:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA26946 for hackers-outgoing; Fri, 8 Aug 1997 17:48:10 -0700 (PDT) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA26936 for ; Fri, 8 Aug 1997 17:48:06 -0700 (PDT) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id TAA01809; Fri, 8 Aug 1997 19:53:06 GMT X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Fri, 8 Aug 1997 19:53:06 +0000 (GMT) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: Terry Lambert cc: hackers@FreeBSD.ORG Subject: Re: reset screen hardware? In-Reply-To: <199708082055.NAA27986@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I don't get it, aren't all SVGA cards the same when i comes down to text modes as well as regular VGA modes? 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? 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? > > Last night X crashed on me, i thought my machine needed to be rebooted, > > but first i tried to telnet into it, i was able and i killed X and had to > > restart X twice to get it to work, well everything seemed fine after that, > > however my Text consols were all fubar'd and i had no idea how to reset > > the text part of my display to i wound up rebooting anyway. > > > > What could i have done to reset the text screens? > > You could have modified X to use a DDX in the kernel so that when > the X server was killed, the kernel driver would be able to restore > the video card to the pre-X server state. > > Failing that, the console driver has no idea what the X server > has done to the I/O ports and video card reigsters; not knowing > what was done to the card means it can't know how to undo it. > > So, you could have tried to less destructively kill the X server > (kill -1 or -15 instead of -9) and prayed the signal handler did > the cleanup. If it didn't, there was nothing you could do, period. > > This is a basic problem with the design of the X-server/video card > interface for user space X server code. Nothing short of a redesign > can really fix it. > > > By the same token, the kernel debugger can't restore the video state > when you drop into the kernel debugger from X in the event of a fault > or debugging trap. > > This is one of my most long-standing gripes with UNIX systems since > the first days of X windows. 8-(. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. >