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

[Anthony Liguori <anthony@codemonkey.ws>]

On Sat, 08 Jul 2006 02:10:09 +0100, Christian Limpach wrote:

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

Actually, neither is really a problem.  The VNC protocol does not specify
which FramebufferUpdates correspond to which FramebufferUpdateRequests. 
There is a nasty race condition present in the VNC protocol related to
this caused by SetPixelFormat.

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

Yeah, I'm not convinced this will work all that well.  The most common
CopyRect is window dragging.  For X, the whole window is moved at once. 
Under Windows, the window is broken into smaller rectangles and each are
moved individually.  Because CopyRects always come in groups, and tend to
overlap, things get pretty nasty quickly.  Plus, Windows tends to redraw
the border of a Window when it moves so depending on when you check,
things can be way off.

That's not to say that it won't work for some cases.  A framebuffer
protocol is just a whole lot more deterministic.

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

Are they that expensive compared to what else is going on here?  We're
talking about updates that occur at rather coarse granularities (10-15
times a second).  Seems like the cost wouldn't make much of a difference.

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

Perhaps.  VNC is a little rough around the edges (things like the
SetPixelFormat race are a real pain).  Would be nice to have something
that supported more advanced features though like YUV overlays.

Regards,

Anthony Liguori

>     christian