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


[Xen-devel] Re: [PATCH] qemu vnc updates

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] qemu vnc updates
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Tue, 26 Feb 2008 10:15:51 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 26 Feb 2008 08:16:34 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47C3F6FA.6080506@xxxxxxxxxxxxx>
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: <47C3F6FA.6080506@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20080214)
Stefano Stabellini wrote:
Hi all,
reading qemu code I realized that the qemu vnc server sometimes sends framebuffer updates even if the client didn't request any. This is not consistent with the RFB protocol spec and can break some clients.

It's actually consistent with the RFB spec. Have you seen any clients break?

The RFB spec states pretty clearly that a single FramebufferUpdateRequest may generate 0 or more FramebufferUpdate events. Once a client has sent a single FramebufferUpdate request, it should expect to continue to receive more FramebufferUpdates for an indefinite period of time according to the specification.


Anthony Liguori

The patch I am attaching strictly enforces compliance with the RFB protocol making sure framebuffer updates are sent only if the client requested one. Doing so is more difficult than it seems because some framebuffer pseudo-encoding updates cannot be discarded but must be sent anyway: for example desktop resize and pixel format change messages. To solve the problem I wrote a queue that stores those messages and sends them as soon as the client asks for an update. Since 90% of the times the queue is used to store only few elements, the queue allocates 10 elements at the beginning and every time it runs out of elements allocates other 10 elements. This is should drastically limit the number of malloc and free needed to maintain the queue.
I did some stress tests in the last couple of days and seems to work well.
Best Regards,

Stefano Stabellini

Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>


Xen-devel mailing list

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>