[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 10/11] vnc: move initialization to framebuffer_update_request

From: Gerd Hoffmann
Subject: Re: [PULL 10/11] vnc: move initialization to framebuffer_update_request
Date: Fri, 22 Jan 2021 14:42:13 +0100

On Fri, Jan 22, 2021 at 01:49:38PM +0100, Laszlo Ersek wrote:
> On 01/22/21 09:46, Gerd Hoffmann wrote:
> >> This patch breaks QEMU for me.
> > 
> >> The symptom is the following: in virt-manager, the display remains dead
> >> (black), when I start an OVMF guest. At the same time, unusually high
> >> CPU load can be seen on the host; it makes me think that virt-manager is
> >> trying, in a busy loop, to complete the VNC handshake, or some such.
> >> Ultimately, although the guest boots up fine, virt-manager gives up, and
> >> the display window says "Viewer was disconnected".
> > 
> > It is the vnc_colordepth() call. Seems gtk-vnc sends a update request
> > with incremental=0 as response to the VNC_ENCODING_WMVi message.  So
> > sending that as response to an incremental=0 update request creates an
> > endless loop ...
> Interesting; I saw that commit 9e1632ad07ca *added* (as opposed to
> *moving*) the vnc_colordepth() call; I thought it was a relatively
> insignificant bit...

/me too.

Some discussions in the resize changes indicated that the idea of a
non-incremetal update request is that the server sends the *full*
server-side state, so the client can render the screen properly without
remembering old state.

So I thought ok, lets send the colordepth info too, no big deal ...

take care,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]