Re: [Xen-devel] Re: [PATCH 2/2] Virtual frame buffer: user space backend

["Christian Limpach" <christian.limpach@xxxxxxxxx>]

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?

   christian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel