Re: [PATCH v3 2/3] vnc: move initialization to framebuffer_update_request

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH v3 2/3] vnc: move initialization to framebuffer_update_request
Date: Thu, 14 Jan 2021 17:39:18 +0000	[thread overview]
Message-ID: <20210114173918.GU1643043@redhat.com> (raw)
In-Reply-To: <20210112134120.2031837-3-kraxel@redhat.com>

On Tue, Jan 12, 2021 at 02:41:19PM +0100, Gerd Hoffmann wrote:
> qemu sends various state info like current cursor shape to newly connected
> clients in response to a set_encoding message.  This is not correct according
> to the rfb spec.  Send that information in response to a full (incremental=0)
> framebuffer update request instead.  Also send the resize information
> unconditionally, not only in case of an actual server-side change.
> 
> This makes the qemu vnc server conform to the spec and allows clients to
> request the complete vnc server state without reconnect.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  ui/vnc.c | 11 ++++-------
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/ui/vnc.c b/ui/vnc.c
> index 84c4972b895b..8df63b349b38 100644
> --- a/ui/vnc.c
> +++ b/ui/vnc.c
> @@ -660,10 +660,6 @@ static void vnc_desktop_resize(VncState *vs)
>      if (vs->ioc == NULL || !vnc_has_feature(vs, VNC_FEATURE_RESIZE)) {
>          return;
>      }
> -    if (vs->client_width == pixman_image_get_width(vs->vd->server) &&
> -        vs->client_height == pixman_image_get_height(vs->vd->server)) {
> -        return;
> -    }
>  
>      assert(pixman_image_get_width(vs->vd->server) < 65536 &&
>             pixman_image_get_width(vs->vd->server) >= 0);
> @@ -2013,6 +2009,10 @@ static void framebuffer_update_request(VncState *vs, int incremental,
>      } else {
>          vs->update = VNC_STATE_UPDATE_FORCE;
>          vnc_set_area_dirty(vs->dirty, vs->vd, x, y, w, h);
> +        vnc_colordepth(vs);
> +        vnc_desktop_resize(vs);
> +        vnc_led_state_change(vs);
> +        vnc_cursor_define(vs);

If I'm nit-picking this still isn't spec compliant as it is sending
4 separate framebuffer update messages each with 1 rectangle, in
response to 1 single framebuffer update request.

The strictly spec compliant approach would be to put these on a queue
and send them as rectangles in the frame buffer update message that's
sending the framebuffer contents. IIUC, this is the approach tigervnc
uses.  This would require a major change in the way QEMU sends FB
update messages though.

In reality I doubt there are VNC clients that really care about this
distinction, and this change is still more spec compliant
that the current impl.

>      }
>  }
>  
> @@ -2136,10 +2136,7 @@ static void set_encodings(VncState *vs, int32_t *encodings, size_t n_encodings)
>              break;
>          }
>      }
> -    vnc_desktop_resize(vs);
>      check_pointer_type_change(&vs->mouse_mode_notifier, NULL);
> -    vnc_led_state_change(vs);
> -    vnc_cursor_define(vs);
>  }
>  
>  static void set_pixel_conversion(VncState *vs)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|