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: [PATCH 2/2] Virtual frame buffer: user space backend

To: "Anthony Liguori" <anthony@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 2/2] Virtual frame buffer: user space backend
From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
Date: Sat, 8 Jul 2006 02:10:09 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 07 Jul 2006 18:10:31 -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=j4Q14ff4Awyz75OzYglYX65zh8GjOHE2IyzwSIUd6KETgjtEuTxrwwUQ0IxL71JOD/1+4XoveSrGzeL3jp0dOkGF5WrwVWNMKCUysBqup/zJC9qd3SCZESO/MON9/6k16JFulmdXak3Uwdwvby/Z0qor5JqK4zVW5/lEcBOAu+Y=
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.> <3d8eece20607071550i7fcc98d7o634db68ec6d25b9c@xxxxxxxxxxxxxx> <pan.2006.>
Reply-to: Christian.Limpach@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 7/8/06, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
On Fri, 07 Jul 2006 23:50:32 +0100, Christian Limpach wrote:
> Doesn't your virtual framebuffer already support 2d operations?

Nope.  X won't even bother using the interface.  Plus, serializing 2d ops
is quite challenging when dealing with a shared buffer.

That's a shame.

> Also, the
> cirrus driver emulation in qemu already supports copyrect.

I know, I added support for it.  It was really painful to get right too
since the vga memory has to be flushed before the copyrect occurs (and the
system has to disallow more writes until the copyrect completes).

Indeed, it was actually still a bit broken, relying on being able to
send updates to the client even when the client hadn't requested an
update yet.  Also the case where the source or destination rects are
not within the client's area is not really handled.

It's going to be even more painful in Xen since the cost of that
serialization is going to be greater.

We thought we could pass the copyrect information as a hint and then
only vnc-copyrect the areas which are still intact.

>> 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.

Why?  That seems odd to me.

They're expensive on SMP systems?

>> I think the key point is to have the bitmap represent linear regions of
>> framebuffer memory instead of logical rectangles within the current
>> resolution.
> Well, I don't agree ;-)  Because we want to transport 2D redraw
> information from the frontend to the backend.

So 2D information is very useful, especially for VNC.  I think for Xen
though, we may need to abandon the shared framebuffer completely and
develop a lightweight framebuffer protocol.

The idea would be to push the dirty'ing analysis to the frontend and have
it communicate data over a higher bandwidth ring queue.  This avoids
having to deal with synchronizing the shared framebuffer for 2d ops.

This is quite a bit different from the code today though.

What do you think about getting rid of the shared framebuffer altogether?

Not sure, it could be an option.  Might as well use VNC as the protocol then?


Xen-devel mailing list