From patchwork Wed Aug 29 10:14:57 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alon Levy X-Patchwork-Id: 180678 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 4FE072C00BB for ; Wed, 29 Aug 2012 20:15:34 +1000 (EST) Received: from localhost ([::1]:33839 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6fJ6-0007wy-AT for incoming@patchwork.ozlabs.org; Wed, 29 Aug 2012 06:15:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53820) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6fIx-0007pb-QT for qemu-devel@nongnu.org; Wed, 29 Aug 2012 06:15:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6fIm-00015s-5o for qemu-devel@nongnu.org; Wed, 29 Aug 2012 06:15:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6fIl-000147-Te for qemu-devel@nongnu.org; Wed, 29 Aug 2012 06:15:12 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7TAF6mD017535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Aug 2012 06:15:06 -0400 Received: from garlic.redhat.com (vpn-8-1.rdu.redhat.com [10.11.8.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q7TAEwod005172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 29 Aug 2012 06:15:03 -0400 Date: Wed, 29 Aug 2012 13:14:57 +0300 From: Alon Levy To: =?iso-8859-1?Q?S=F8ren?= Sandmann Message-ID: <20120829101457.GC32547@garlic.redhat.com> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2011-07-01) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id q7TAF6mD017535 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 Cc: =?iso-8859-1?Q?S=F8ren?= Sandmann Pedersen , Gerd Hoffmann , spice-devel@freedesktop.org, qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [Spice-devel] [PATCH] Add new client_present and client capabilities fields to QXLRom X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Wed, Aug 29, 2012 at 02:58:14AM +0200, Søren Sandmann wrote: > Gerd Hoffmann writes: > > > On 08/27/12 19:20, Søren Sandmann Pedersen wrote: > >> From: Søren 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? > > Is this case supported at all? > > 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 the > intersection of all the clients. > > > 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 ... > > Good question. > > I don't know of a good way to deal with the situation where the new > client is unable to handle existing surfaces. I suppose in principle > spice-server could emulate their existence, sending them as images, but > I'm not familiar enough with spice-server to say whether that is > feasible. Sending a surface with a format the client doesn't recognize as an image - how does that help? you'd want to render anything dependent on that surface. And then the guest will be notified of the reduced capabilities and needs to never use those surfaces again (better yet, destroy them since they are just taking space). The rendering is already accomplished in on_new_display_channel_client with the red_flush_current(worker, 0) call, which recursively goes to all the dependent surfaces of each drawable and renders it too. > > For commands, would it work for spice-server to just process everything > in the command ring after changing the capability bits (ie., in possibly > brief moment before a new client connects)? It seems that would be a > good thing to do even without capability bits. This should work. Something like this I guess: (probably only if capabilities have changed - otherwise no need. And without MAX_PIPE_SIZE, although I'm not sure what you would put instead.): > > > Søren > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel --- a/server/red_worker.c +++ b/server/red_worker.c @@ -9493,6 +9493,10 @@ static void on_new_display_channel_client(DisplayChannelClient *dcc) } red_channel_client_ack_zero_messages_window(&dcc->common.base); if (worker->surfaces[0].context.canvas) { + int ring_is_empty; + + while (red_process_commands(worker, MAX_PIPE_SIZE, &ring_is_empty)) { + } red_current_flush(worker, 0); push_new_primary_surface(dcc); red_push_surface_image(dcc, 0);