From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH 8/9] vnc: add support for extended desktop resize
Date: Fri, 4 Dec 2020 12:25:10 +0000 [thread overview]
Message-ID: <20201204122510.GG3056135@redhat.com> (raw)
In-Reply-To: <20201204063750.txm24fnbo4vqq4tt@sirius.home.kraxel.org>
On Fri, Dec 04, 2020 at 07:37:50AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > + case VNC_ENCODING_DESKTOP_RESIZE_EXT:
> > > + vs->features |= VNC_FEATURE_RESIZE_EXT_MASK;
> >
> > IIUC, we shouldn't set this flag unless all current displays adapters
> > associated with the VNC server support the "ui_info" callbacks,
> > otherwise the client will think it can send resize requests
> > but they'll never be honoured.
>
> Well, that can happen anyway as honoring the request is in the hands of
> the guest and not something qemu can guarantee. So vnc clients must be
> able to deal with that no matter what. The spec even explicitly states
> that rejecting all resize requests from the client is perfectly valid
> behavior for a server.
Yes, I see we are rejecting requests unconditionally now.
I still think it is valuable to clients to see a difference between
something that is rejected because there is zero chance it will be
honoured, vs something that we are likely honour albeit asynchronously.
So I suggested we have a new error reason to indicate it is being
processed async. If we don't have ui_info, then we should reject
with reason 1 - Resize is administratively prohibited, but if we
can probably honour it, then reject with a new reason 4 to indicate
async handling.
> For tigervnc it seems to make no difference whenever the server supports
> extended desktop resize or not.
>
> I doubt making this conditional buys us anything ...
If we know there is zero chance of this working, then clients can
take different behaviour. For example, we can make the window
non-resizable, or activate scaling of the graphics, instead of
waiting for a resize. So this distinction will be useful to
improve the user experiance of virt-viewer/remote-viewer IMHO.
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 :|
next prev parent reply other threads:[~2020-12-04 12:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 11:07 [PATCH 0/9] vnc: support some new extensions Gerd Hoffmann
2020-12-03 11:07 ` [PATCH 1/9] console: allow con==NULL in dpy_set_ui_info Gerd Hoffmann
2020-12-04 11:28 ` Marc-André Lureau
2020-12-03 11:07 ` [PATCH 2/9] console: add check for ui_info pointer Gerd Hoffmann
2020-12-04 11:32 ` Marc-André Lureau
2020-12-03 11:07 ` [PATCH 3/9] vnc: use enum for features Gerd Hoffmann
2020-12-04 11:32 ` Marc-André Lureau
2020-12-03 11:08 ` [PATCH 4/9] vnc: drop unused copyrect feature Gerd Hoffmann
2020-12-04 11:32 ` Marc-André Lureau
2020-12-03 11:08 ` [PATCH 5/9] vnc: add pseudo encodings Gerd Hoffmann
2020-12-04 11:34 ` Marc-André Lureau
2020-12-03 11:08 ` [PATCH 6/9] vnc: add alpha cursor support Gerd Hoffmann
2020-12-04 11:39 ` Marc-André Lureau
2020-12-03 11:08 ` [PATCH 7/9] vnc: force initial resize message Gerd Hoffmann
2020-12-04 11:57 ` Marc-André Lureau
2020-12-08 6:57 ` Gerd Hoffmann
2020-12-08 8:02 ` Marc-André Lureau
2020-12-03 11:08 ` [PATCH 8/9] vnc: add support for extended desktop resize Gerd Hoffmann
2020-12-03 11:28 ` Daniel P. Berrangé
2020-12-04 6:37 ` Gerd Hoffmann
2020-12-04 12:25 ` Daniel P. Berrangé [this message]
2020-12-04 12:15 ` Daniel P. Berrangé
2020-12-04 12:24 ` Marc-André Lureau
2020-12-03 11:08 ` [PATCH 9/9] qxl: add ui_info callback Gerd Hoffmann
2020-12-04 12:20 ` Daniel P. Berrangé
2020-12-04 12:45 ` Marc-André Lureau
2020-12-04 12:50 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201204122510.GG3056135@redhat.com \
--to=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).