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