Date: Mon, 3 Apr 1995 22:12:36 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-hackers@FreeBSD.org (FreeBSD hackers) Subject: Re: grafx console & DDB Message-ID: <199504032012.WAA00745@uriah.heep.sax.de> In-Reply-To: <9504031838.AA07543@cs.weber.edu> from "Terry Lambert" at Apr 3, 95 12:38:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Terry Lambert wrote: > > > 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. Of course, but it's even harder to make than the vm86() story. In case of a panic(), almost everything it's lost, so i don't really care if the X server shuts down nicely. > 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 ..., 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. ... I didn't think of that. Perhaps vm86() should always run non- privileged (except of the IOPL), and the GP fault being ignored? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504032012.WAA00745>