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