yeahuh / rpms / qemu-kvm

Forked from rpms/qemu-kvm 2 years ago
Clone

Blame SOURCES/kvm-ui-correctly-reset-framebuffer-update-state-after-pr.patch

5d360b
From 3d48415578c65490675616d41a32a1e9e3a71f43 Mon Sep 17 00:00:00 2001
5d360b
From: "Daniel P. Berrange" <berrange@redhat.com>
5d360b
Date: Thu, 8 Feb 2018 17:50:34 +0100
5d360b
Subject: [PATCH 20/27] ui: correctly reset framebuffer update state after
5d360b
 processing dirty regions
5d360b
MIME-Version: 1.0
5d360b
Content-Type: text/plain; charset=UTF-8
5d360b
Content-Transfer-Encoding: 8bit
5d360b
5d360b
RH-Author: Daniel P. Berrange <berrange@redhat.com>
5d360b
Message-id: <20180208175041.5634-21-berrange@redhat.com>
5d360b
Patchwork-id: 78941
5d360b
O-Subject: [RHEL-7.5 qemu-kvm PATCH v1 20/27] ui: correctly reset framebuffer update state after processing dirty regions
5d360b
Bugzilla: 1527405
5d360b
RH-Acked-by: Laszlo Ersek <lersek@redhat.com>
5d360b
RH-Acked-by: Gerd Hoffmann <kraxel@redhat.com>
5d360b
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
5d360b
5d360b
From: "Daniel P. Berrange" <berrange@redhat.com>
5d360b
5d360b
According to the RFB protocol, a client sends one or more framebuffer update
5d360b
requests to the server. The server can reply with a single framebuffer update
5d360b
response, that covers all previously received requests. Once the client has
5d360b
read this update from the server, it may send further framebuffer update
5d360b
requests to monitor future changes. The client is free to delay sending the
5d360b
framebuffer update request if it needs to throttle the amount of data it is
5d360b
reading from the server.
5d360b
5d360b
The QEMU VNC server, however, has never correctly handled the framebuffer
5d360b
update requests. Once QEMU has received an update request, it will continue to
5d360b
send client updates forever, even if the client hasn't asked for further
5d360b
updates. This prevents the client from throttling back data it gets from the
5d360b
server. This change fixes the flawed logic such that after a set of updates are
5d360b
sent out, QEMU waits for a further update request before sending more data.
5d360b
5d360b
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
5d360b
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
5d360b
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
5d360b
Message-id: 20171218191228.31018-8-berrange@redhat.com
5d360b
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
5d360b
(cherry picked from commit 728a7ac95484a7ba5e624ccbac4c1326571576b0)
5d360b
Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
5d360b
---
5d360b
 ui/vnc.c | 2 +-
5d360b
 1 file changed, 1 insertion(+), 1 deletion(-)
5d360b
5d360b
diff --git a/ui/vnc.c b/ui/vnc.c
5d360b
index 7239602..075def1 100644
5d360b
--- a/ui/vnc.c
5d360b
+++ b/ui/vnc.c
5d360b
@@ -910,7 +910,7 @@ static int vnc_update_client(VncState *vs, int has_dirty)
5d360b
     }
5d360b
 
5d360b
     vnc_job_push(job);
5d360b
-    vs->update = VNC_STATE_UPDATE_INCREMENTAL;
5d360b
+    vs->update = VNC_STATE_UPDATE_NONE;
5d360b
     vs->has_dirty = 0;
5d360b
     return n;
5d360b
 }
5d360b
-- 
5d360b
1.8.3.1
5d360b