| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: Framebuffer (was [Xen-devel] Xen port of ReactOS)
> From: Ian Pratt
>
> The intention is to have a shared memory bitmap frame buffer,
> with a 'side channel' into which information about which
> rectangles of the screen have been blited, filled, copied etc
> can optionally be sent.
>
> In dom0 we can use vnclib to export the disaply over the
> 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é van Geldorp.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home