From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6bKK-0003cn-Uq for qemu-devel@nongnu.org; Wed, 29 Aug 2012 02:00:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6bKD-0006Pf-LT for qemu-devel@nongnu.org; Wed, 29 Aug 2012 02:00:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6bKD-0006P8-Bq for qemu-devel@nongnu.org; Wed, 29 Aug 2012 02:00:25 -0400 Message-ID: <503DAFEF.4040701@redhat.com> Date: Wed, 29 Aug 2012 08:00:15 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1346088041-17062-1-git-send-email-sandmann@cs.au.dk> <1346088041-17062-2-git-send-email-sandmann@cs.au.dk> <503C621D.80805@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] Add new client_present and client capabilities fields to QXLRom List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?U8O4cmVuIFNhbmRtYW5u?= Cc: qemu-devel@nongnu.org, spice-devel@freedesktop.org, =?UTF-8?B?U8O4cmVu?= =?UTF-8?B?IFNhbmRtYW5uIFBlZGVyc2Vu?= On 08/29/12 02:58, S=C3=B8ren Sandmann wrote: > Gerd Hoffmann writes: >=20 >> On 08/27/12 19:20, S=C3=B8ren Sandmann Pedersen wrote: >>> From: S=C3=B8ren Sandmann Pedersen >>> >>> The client_present field is a byte that is set of non-zero when a >>> client is connected and to zero when no client is connected. >>> >>> The client_capabilities[58] array contains 464 bits that indicate the >>> capabilities of the client. >> >> What is supposed to happen in case multiple clients are connected? >=20 > Is this case supported at all? There is code for it, although disabled by default and nobody actively working in it as far I know. We should at least have a plan how to handle that situation ... > If it is, I'd say that the guest should not be aware of it and the bits > advertise should be interpreted as "these are the capabilities that > spice-server will marshall on to the clients that are > connected". Presumably spice-server would then set the bit vector to th= e > intersection of all the clients. Makes sense. >> How do you handle the race conditions, especially on capability >> downgrade? There might be not-yet processed commands in the command >> queue which the client is unable to handle, or existing surfaces using >> formats the client doesn't understand ... >=20 > Good question.=20 >=20 > I don't know of a good way to deal with the situation where the new > client is unable to handle existing surfaces. We need a sensible solution here. If we can't handle capability downgrade at runtime the capability negotiation between guest and client doesn't make sense in the first place. Failing that we can add a a8 switch to qxl. When enabled qemu asks spice-server to enable a8, which in turn will raise the display channel minor version, basically requiring an updated spice client to connect. With a8 disabled old clients can connect too. > For commands, would it work for spice-server to just process everything > in the command ring after changing the capability bits (ie., in possibl= y > brief moment before a new client connects)? It seems that would be a > good thing to do even without capability bits. spice server could process (aka server-side rendering) all outstanding commands after updating capability bits and before starting to forward commands to the new client. Yes, that should work. cheers, Gerd