[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |