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: [Xen-devel] Re: Re: [PATCH 2/2] Virtual frame buffer: user space bac

To: "Anthony Liguori" <anthony@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Re: [PATCH 2/2] Virtual frame buffer: user space backend
From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
Date: Fri, 7 Jul 2006 23:50:32 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 07 Jul 2006 15:50:56 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ADfbfQlbmwDr545jfPJi+5Bv6hbaZZfQr/qSog6VBotM7AS/yj4sGBEswUNmKRTVfr435bi47cj+E/MQBL21MCzT265V9yS7jM9icVbQINMQDowcrsQLTprKAPYkMyG4p+Ey0tDR8M6gd04+2yVkTYBXQTYstNN+nOYQwuslI1M=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <pan.2006.>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <87ac80ghox.fsf@xxxxxxxxxxxxxxxxx> <871wtcghmr.fsf@xxxxxxxxxxxxxxxxx> <3d8eece20607070957p2d6bb1e5o7febaa5ca124429d@xxxxxxxxxxxxxx> <pan.2006.> <3d8eece20607071133m10b3a279hac1229bdcdf38bf4@xxxxxxxxxxxxxx> <pan.2006.>
Reply-to: Christian.Limpach@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 7/7/06, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
Since the best we can do is page granularity (for now), why not just have
a bitmap represent the dirty pages?

Doesn't your virtual framebuffer already support 2d operations?  Also,
the cirrus driver emulation in qemu already supports copyrect.

Instead of switching bitmaps, why not
just have the backend and frontend share a bitmap and do atomic get/sets
on it?

Because we'd like to avoid atomic operations.

I think the key point is to have the bitmap represent linear regions of
framebuffer memory instead of logical rectangles within the current

Well, I don't agree ;-)  Because we want to transport 2D redraw
information from the frontend to the backend.


Xen-devel mailing list