Date: Tue, 4 Apr 1995 12:11:00 +0200 From: Thomas Roell <roell@informatik.tu-muenchen.de> To: hasty@star-gate.com, terry@cs.weber.edu Cc: freebsd-hackers@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de Subject: Re: grafx console & DDB Message-ID: <95Apr4.121110met_dst.42270@papa.informatik.tu-muenchen.de>
next in thread | raw e-mail | index | archive | help
>>>> Terry Lambert said: > > > > I think I could argue against the VM86() story from another angle > > as well; a VM86() call to video BIOS is no more likely to be able > > to restore from a wierd video mode than a BIOS call would be able > > to reset 16550 serial ports out of FIFO mode. In other words, the > > BIOS might not know how to reset the modes, or if it does, it > > might not know how to reset everything that needs to be reset if > > the mode wasn't established using the BIOS in the first place. > >Hmm... >The above is a bit of speculation and it solely dependent upon the >BIOS implementation. We could change the X server to make VM86 call >to set the vga resolution or the call could be issue from the console >driver and it will save a lot of headaches;additionally >we could provide and option to use the current mode setting in the >X server for those rare exquisite moments in which someone wants to >play with vga sync parameters ... > > Now all what we need is the VM86 call :) Intresting idea. I have tried this for our X-Server about 2 years ago. That's why the internal architecture looks so much different than any other X-Server ;-) Was also able to use SVPMI for initialisation ;-) Now to the problems with calling the BIOS under a VM86 mode: 1/ You MUST have a full VBE implementation in the EPROM. Without that you cannot do anything beyond 640x480. 2/ You MUST be able to read the BIOS under all circumstances. This is very difficult given the many broken cards out there, which have some problems reading the bios, while the processor is in protected mode. The mach64 based ISA boards are such bad examples. 3/ You can only use the BIOS for setting/unsetting graphics modes. Since most of the BIOSes only setup things for plain memory mapped framebuffer acesses you have to do a significant amount of postprocessing to get the graphics engine into accelerated mode. Of course you have to workaround dozens of wrong set bits due to either BIOS bugs, or a unintended usage of them for accelerated modes. Worse, you have to restore all those bits again by hand when you want to go back to text mode. To make things even worse, the dumb framebuffer modes normally have a different scanline-pitch than the one you need for the graphics accelerator. Hence it's basically impossible to use the BIOS for accelerated modes if you still want to have an advantage over directly setting the graphics mode by hand. 4/ There is often no way to set the screen refresh rate, or even to query it. Most VBE BIOSes hence are very conservative and offer you only interlaced modes bejond 800x600. 5/ Many routines that set graphics modes are inherently timing dependant. That means a outb() is assumed to take a fixed known amount of time. If this takes to much time then the routine will fail. Since under VM86 you have to emulate the in/out stuff in your VM86-Monitor, this behaviour is not guaranteed. This fact will break programming of programmable clocks or similar stuff. 6/ For whatever you do with VM86, you loose around 1MB virtual memory (aehm +64k of highmem or whatever this was called). Out of those you need around 16k for the BIOS RAM area plus 32k+64k for mapping the things. So you loose around 128k of memory for just doing that. 7/ The current XF**K86 architecture is completely unusable for a VBE mode-setting. They work with explicite state-saves/restores. With VBE you rather have SetText and SetGraphics instead. Also if you start using VBE you have to use the BIOS also for doing banking and manipulating the CLUT. Very tricky ... 8/ Implementing VBE calls in the server itself is kind of risky, since you might overwrite the copied bios by a mad running server. And this could do quite some harm. But implementing VBE calls in a seperated daemon, like SCO does makes banking expensive, unless you go back to do banking in a graphics chip dependant way. Summararing said, VBE calles under VM86 are not a very good idea. It's only usable for dumb framebuffer drivers. And it has serious limitation. What I have been thinking of is to simply write a 8086 emulator, so I don't need the VM86 handling anymore, which is not implemented everywhere. However this would be a major task, and I doubt that it buys you a lot of advantage over just writing a driver. - Thomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?95Apr4.121110met_dst.42270>