> Apr 2 23:11:21 japh kernel: VBE: No protected mode interface
> Apr 2 23:11:21 japh kernel: VBE BIOS version 1.2 detected
> Apr 2 23:11:21 japh kernel: - version 2 required
>
> I use the SYSTEMSOFT VLSI EAGLE II BIOS 2.00.00 (it is
> the latest HP offers, there is a 2.00.01 with minor changes to harddisk
> addressing anounced, I will try this later). SYSTEMSOFT offers no BIOS
> updates to endusers, but I will ask HP for a new release.
>
> Probably you know the XFree86-FAQ http://www.XFree86.org/FAQ.
> There is a part Q.F22 explaining VESA support for X is "... of no use
> when
> using a protected-mode
> operating system." .
Well.. for some svgalib related stuff I checked out the VBE extensions
some days ago. From other correspondence, I see there are the following
misunderstandings about VESA:
1) It is not a standard for graphic cards. It is a BIOS extension,
a standard for the calls to a DOS driver.
2) Some cards have a VBE in ROM, some don't and need a DOS TSR to do it.
This makes it even more difficult to use it.
3) In principle (read below) VBE is still a real mode DOS driver. To call
it from linux, you must enter real mode. YOu might have to allow it to
call other parts of the BIOS, you might have to setup a fully booted
DOS session.. Noone knows. Things like setting up a 16bit (but
protected mode) code segment and call the VBE bios code there might or
might not work, depending on the actual VBE implementation.
Ryan Rubley <rubleyr@river.it.gvsu.edu> writes/has written a tool which
traces all I/O done by the VBE driver and uses this info to mimic it
with a protected mode driver. There are some (maybe impossible to fix)
problems with this general approach and his specific implementation.
But it should work this way for many cards already. Note, this beast is
in an early implementation state. Some more tests are being done.
4) It seems VBE drivers are still imperfect, esp. when it comes to VBE
2.0. Just look at the UNIVBE software which claims to have a need for
actually working VBE drivers instead of those already coming with the
cards.
Finally, I mentioned that VBE 2.0 is still real mode only:
5) VBE 2.0 does
give access to functions callable in protected mode, but ONLY to set
colors in the color lookup table and to do page flips when no linear
frame buffer is used. It is clear to me that this is intended for games
which switch graphics modes using a DOS extender and only change colors
and page flip directly from protectmode for performance reasons.
For linux, you also want to set modes in protected mode. This is not
supported.
Hence, the Xfree comment is still true in a sense, as you can't easily
start a graphics screen from protected mode. The new interface only speeds
up a few time critical things, but it doesn't make the thing
anything simpler at all.
Now, 'can't easily' does not mean impossible (although system stability
might also suffer from the REAl<->Protected flips.). It's interesting
though, that from all of these guys telling me in private mail how f*
stupid I am, because being unable (or unwilling) to code such a plain
simple VESA driver, I never got a single line of working code.
In the driver above, it might well be, that some graphics mode is selected
during bootup once (still in real mode) and just used all the time. The
remaining page flips and color sets can then be done from protected mode
with VBE 2.0 indeed. This, but nothing more.
Actually, as most people seem to be happy with an X style setup (that is
one screen rez al lthe time (maybe with some text console, which can
easily be emulated in software), this doesn't sound like such a weird idea
to me. After all, countless Sun and other systems work in a way like this.
That is, without many video modes and some software text emulation. I'd
miss support for several video modes though.
If he manages to call the rest of the VBE from protected mode, working on
a majority of cards with no instabilities at all: Let me deerly
congratulate the coder, plus expressing the wish to have a look at this
masterpiece of code (in the hope it is not just a tweaked dosemu for the
BIOS calls only).
On Fri, 3 Apr 1998, Alan Cox wrote:
> This is true for VESA 1 but a lot less true for VESA 2.0. The original
> VESA bios extensions are basically 16bit non-reentrant add ons to the
original
> PC bios graphical support. The 2.0 ones have a 32bit interface which
does
> sort of meet the needs but has a reputation for poor performance.
I'm not away of any 32bit interface in 2.0 other than for setting palette
and page flips. In principle, these (most timecritical) routines, could be
implemented fast with this approach (you can even copy the code to
faster ram), but of course, there is no cure against stupid programmers.
Mode setup routines I won't call time critical. But they are still real
mode only. Or is there a newer VBE 2.0 spec out? I'm not aware of any.
Note that due to what I read, VBE 2.0 is also still a draft only, no
standard.
Michael.
--Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de, or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on any machine in the net, it's very likely it's me.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu