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 :|
