From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95871C4361A for ; Fri, 4 Dec 2020 12:26:25 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0EEFD22A84 for ; Fri, 4 Dec 2020 12:26:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0EEFD22A84 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:43962 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1klAAK-0005WA-0l for qemu-devel@archiver.kernel.org; Fri, 04 Dec 2020 07:26:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1klA9O-0004he-GF for qemu-devel@nongnu.org; Fri, 04 Dec 2020 07:25:26 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:28747) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1klA9M-0005PD-8n for qemu-devel@nongnu.org; Fri, 04 Dec 2020 07:25:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607084723; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=yXK5A1u9IPDN7PO2gna7l2tZ7qN8qHKRAZ0hIBaJ23g=; b=a4EUCgZ/kvykh35JK+S5mq04iWLKNaJ7cfvh249CFxEW+KcmSVtsZP+wQbq/PMoNi3mRJ/ 1+wm7TLgFAK4UbFMOBW9Gym+aA7HTCDYl5NtxYzMFI30C8FUR8qo7gtl1iKQjpt2gAn0LO 7rsV+q5w8bUFvyq53HgPyLOFe7RjlLo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-329-H64zSoagO_Sc6Eg1n9b9bQ-1; Fri, 04 Dec 2020 07:25:18 -0500 X-MC-Unique: H64zSoagO_Sc6Eg1n9b9bQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C4A89858182 for ; Fri, 4 Dec 2020 12:25:17 +0000 (UTC) Received: from redhat.com (ovpn-115-10.ams2.redhat.com [10.36.115.10]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EEB9A5C1D1; Fri, 4 Dec 2020 12:25:13 +0000 (UTC) Date: Fri, 4 Dec 2020 12:25:10 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Gerd Hoffmann Subject: Re: [PATCH 8/9] vnc: add support for extended desktop resize Message-ID: <20201204122510.GG3056135@redhat.com> References: <20201203110806.13556-1-kraxel@redhat.com> <20201203110806.13556-9-kraxel@redhat.com> <20201203112845.GC2952498@redhat.com> <20201204063750.txm24fnbo4vqq4tt@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: <20201204063750.txm24fnbo4vqq4tt@sirius.home.kraxel.org> User-Agent: Mutt/1.14.6 (2020-07-11) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=216.205.24.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.496, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 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 :|