Here's my current take:
Use VESA's VBE (http://www.vesa.org/vbe3.pdf) to talk to the host from
within guest space.
Advantages:
VBE maps simply onto SDL.
VBE is a well-defined hardware interface.
A fair number of apps will support VBE without us writing a driver at all.
All the special handling needed is INT 10 being redirected to the user-space
monitor on the host, and then handled by the GUI plugin, which needs to be
able to rw into the guest space (into selections that are writable with
native guest writes).
We could allow PM interfaces that VBE gives as optional in PM trivialy,
since we won't really be running inside the host at all.
Disadvantages:
Not quite as fast as speaking SDL directly. But SDL is a library, not a hw
standard anyway; it doesn't make sense to speak it directly, any more then
you can speak written Japanese[1] directly -- you need to map the
idiograms/funtions into sounds/interrupts.
VBE still doesn't give us a spec for HW accel stuff. We could use VBE/AF
(Accelerated Functions) for that part, which looks like a good spec, but is
expensive and not well supported. I'm looking around at stuff for that.
VBE dosn't spec 3d stuff at all. I suggest that we make VBE OEM extention
that translates OpenGL into somthing VBE-like (IE a hardware spec, not a
library). That would make it trivial to write OpenGL drivers, and after
you've got an OpenGL driver, there's a generic Direct3D driver that will work.
Anybody else have some pros or cons? It looks to me like the pros outweigh
the cons.
-=- James Mastros
[1] Beg pardon to anybody who remembers what subset of Japanese is
idiographic -- I'm not even certian that I mean Japanese and not a Chinese.
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU>CS d->-- s-:- a20 C++ UL+++@ P+++>+++++ L++@ E-() N o? K? w@ M-- !V
PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e>++ h! r- y?
------END GEEK CODE BLOCK------
