This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Ge van Geldorp" <gvg@xxxxxxxxxxx>, "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>, "James Harper" <james.harper@xxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: RE: Framebuffer (was [Xen-devel] Xen port of ReactOS)
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 25 Mar 2005 10:53:36 -0000
Cc: <ian.pratt@xxxxxxxxxxxx>
Delivery-date: Fri, 25 Mar 2005 10:54:57 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Thread-index: AcUxJ6glkHHHbQk1QlyulJ5Zv6aIdgAACw2Q
Thread-topic: Framebuffer (was [Xen-devel] Xen port of ReactOS)
> > 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?

Doing it in domU works fine, but isn't tranparent to the guest.
> 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).

This works fine for full-screen desktop use, but you do have to
'swizzle' the framebuffer for normal ram when another domain owns the
display. If all the heads are running X, you can probably just use the
SIGUSR1 support that's used for virutal consoles and let X take care of

If you want to share a framebuffer in anything other than full screen
(and care about protection), you need some proper virtualization.


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.
Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>