Date: Mon, 3 Apr 95 12:38:15 MDT From: terry@cs.weber.edu (Terry Lambert) To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.org Subject: Re: grafx console & DDB Message-ID: <9504031838.AA07543@cs.weber.edu> In-Reply-To: <199504021216.OAA01253@uriah.heep.sax.de> from "J Wunsch" at Apr 2, 95 02:16:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Before Terry jumps in: i know that this is not the generic solution. > The console drivers should reinitialize the system's console via a > vm86() call to the video BIOS -- but i don't see this solution around > the corner within the next weeks. Too late. ;-). No, the generic soloution is to not allow the X server direct access to the mode registers, and instead force it to go through a kernel driver. That way, when you get a panic, the kernel can put the mode into something reasonable for the console to be usable without having to send a !@#$%! message to the X server asking it to "please put the console back so I can use it". A useless message when the kernel debugger knows damn well that it is not going to allow the X server a chance to run to do what it was asked anyway, since it could have been the cause of the panic. The problem comes from two drivers setting video modes with non intersecting mode sets for each driver, so no one driver can ever "know" what mode the card is in and restore it to a "sane" mode from that mode. It's vaguely like drawing with a Calcomp plotter, which only has the ability to "goto 0,0" or to "goto relative x,y from here"; you have to keep state about where you are at to get to where you want to be. Making VM86() calls in the BIOS is a way to set video modes on otherwise undocumented hardware... but it is *dangerous*. Most "modern" video cards think it is more important that they not look bad than your system function correctly, and they will disable *all* interrupts while in an INT 10 call rather than looking slow on benchmarks and waiting for the vertical blanking interval to do their jobs. That means making the call could easily lose you important network and/or disk and/or serial traffic. Very bad. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504031838.AA07543>