From 728a7ac95484a7ba5e624ccbac4c1326571576b0 Mon Sep 17 00:00:00 2001 From: "Daniel P. Berrange" Date: Mon, 18 Dec 2017 19:12:22 +0000 Subject: [PATCH] ui: correctly reset framebuffer update state after processing dirty regions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit According to the RFB protocol, a client sends one or more framebuffer update requests to the server. The server can reply with a single framebuffer update response, that covers all previously received requests. Once the client has read this update from the server, it may send further framebuffer update requests to monitor future changes. The client is free to delay sending the framebuffer update request if it needs to throttle the amount of data it is reading from the server. The QEMU VNC server, however, has never correctly handled the framebuffer update requests. Once QEMU has received an update request, it will continue to send client updates forever, even if the client hasn't asked for further updates. This prevents the client from throttling back data it gets from the server. This change fixes the flawed logic such that after a set of updates are sent out, QEMU waits for a further update request before sending more data. Signed-off-by: Daniel P. Berrange Reviewed-by: Darren Kenny Reviewed-by: Marc-André Lureau Message-id: 20171218191228.31018-8-berrange@redhat.com Signed-off-by: Gerd Hoffmann --- ui/vnc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ui/vnc.c b/ui/vnc.c index 30e2feeae3..243c72be13 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -1031,7 +1031,7 @@ static int vnc_update_client(VncState *vs, int has_dirty) } vnc_job_push(job); - vs->update = VNC_STATE_UPDATE_INCREMENTAL; + vs->update = VNC_STATE_UPDATE_NONE; vs->has_dirty = 0; return n; }