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

[Anthony Liguori <anthony@codemonkey.ws>]

On Fri, 07 Jul 2006 23:50:32 +0100, Christian Limpach wrote:

> On 7/7/06, Anthony Liguori <anthony@codemonkey.ws> 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?

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

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

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

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

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

Regards,

Anthony Liguori

>      christian