RE: Framebuffer (was [Xen-devel] Xen port of ReactOS)

[Ge v. G. <gv...@re...>]

> From: Ian Pratt
>=20
> The intention is to have a shared memory bitmap frame buffer,=20
> with a 'side channel' into which information about which=20
> rectangles of the screen have been blited, filled, copied etc=20
> can optionally be sent.
>=20
> In dom0 we can use vnclib to export the disaply over the=20
> network (over SSL) if required, or render it on the local X server.

Being new to Xen, I might be missing something obvious, but what's the
advantage of doing this VNC stuff in dom0? Why not do it in domU?

Would it be feasible to have dom0 manage the VBE framebuffer (just about =
any
graphics card is VBE-compliant these days)? Dom0 would map the frame =
buffer
into the "foreground" domain, so the guest could write directly to the
hardware frame buffer. When another domain is brought to the foreground,
dom0 would copy the bits from the frame buffer to a shadow memory area, =
map
that memory area in place of the frame buffer in the domain which was
previously foreground and give access to the hardware frame buffer to =
the
new foreground domain (after copying the bits from its shadow frame =
buffer).

> Any volunteers?

ReactOS/Windows without GUI is, uhhhm, icky, so I'm definitely =
interested in
this. Just not right now, need to get ReactOS up and running first.

G=E9 van Geldorp.