Date: Sat, 9 Aug 1997 10:22:19 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: perlsta@sunyit.edu (Alfred Perlstein) Cc: terry@lambert.org, hackers@FreeBSD.ORG Subject: Re: reset screen hardware? Message-ID: <199708091722.KAA05031@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.96.970808194922.1801A-100000@server.local.sunyit.edu> from "Alfred Perlstein" at Aug 8, 97 07:53:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? Only from the perspective of the BIOS, and the memory access paradigm for a given standard defined mode ID. The hardware is different. > 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? You can't necessarily reset it by programming the ports (well, you can, if you knew what setting the X server would use if it were doing the job of resetting the card -- probably using more than just ports). The problem is that the card is not put into graphics mode by the console driver, it's put there by a card-specific driver in X. Only the card specific driver in X knows what it did, so only it can undo what it did. > 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? The interrupts do not point to the data. If they did, there would never have been a Diamond graphics card problem (that's actually the *exact* problem with Diamond: the table data was not accessable in a generic fashion from protected mode, and without the table data, there was no figuring out the values to latch into the PAL to get a specific graphic mode -- or even a valid one, necessarily. Mostly because they hired EE's instead of SE's to write their video BIOS, IMO). You *could* write a VM86() and then call the INT 10 call to reset the card. This would require a working VM86() capable of being "thunked", which FreeBSD doesn't have (yet). This assumes that the BIOS code (1) doesn't disable all interrupts while it does it's thing (many cards not using dual ported RAM use this technique to avoid "sparklies"), and (2) it sets all possible modified settings, rather than just remembering a "diff" from the last BIOS mode setting (otherwise you would need to rewrite X to use the VM86() as well, or the BIOS wouldn't reset everything that needed reset). Fun, fun, fun! Terry Lambert terry@lambert.org --- 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?199708091722.KAA05031>