Sounds good. This is what I'm thinking too. Can use
some IO ports (as you mention) to pass info between
the guest video driver and the display code. One
method could be to pass the guest phy addr of a
packet of info via special IO ports. This way
the display code in user space could deal with
arbitrarily large amounts of data without much
IO virtualization overhead.
-Kevin
Wouter Coene wrote:
>
> According to Drew Northup ([EMAIL PROTECTED]):
> > Ok, thanks........ What then provides the support for text-only OS support?
> > (For OS's without a terminal driver......)
>
> Sorry to just kick in, but maybe the following could work:
>
> +----------+ +----------------+
> | VGA BIOS | | special driver |
> +----------+ +----------------+
> - -V- - -V- - - -|- -|- - -|- - -
> +----------+ | | |
> | VGA emu | | | |
> +----------+ | | |
> V V V V V
> +-----------------------------+
> | display code in user |
> +-----------------------------+
>
> Here, the main example of the special driver would be that it bypasses the
> VGA emulation (which is using hardware traps for detecting screen writes or
> something), and thus can optimize for some special cases (window moving,
> plane filling... about anything the guest os would allow it to optimize for).
>
> Programs using the VGA BIOS (or the VGA I/O ports for that matter) would
> simply get emulated by the VGA emu. This would be valid for both text as
> well as graphics modes.
>
> An implementation could involve emulating some VGA card by listening on it's
> I/O ports and doing whatever is expected, and have the special driver
> redirect it's requests to another I/O port or something.
