From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41117) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7LiZ-0007PI-1d for qemu-devel@nongnu.org; Fri, 31 Aug 2012 03:32:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T7LiY-0000CP-0G for qemu-devel@nongnu.org; Fri, 31 Aug 2012 03:32:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7LiX-0000C2-OC for qemu-devel@nongnu.org; Fri, 31 Aug 2012 03:32:37 -0400 Message-ID: <5040688D.5070707@redhat.com> Date: Fri, 31 Aug 2012 09:32:29 +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> <20120829101457.GC32547@garlic.redhat.com> <503EFB6D.1080701@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Spice-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: Alon Levy , qemu-devel@nongnu.org, spice-devel@freedesktop.org, =?UTF-8?B?U8O4cmVuIFNhbmRtYW5uIFBlZGVyc2Vu?= Hi, >> Hmm, when the server is able to translate a8 ops into non-a8 ops using >> server-side rendering, then there is no need to notify the guest about >> the client capabilities. > > To be clear, this ability doesn't exist at the moment, and it would be a > significant chunk of work to add it. > >>> But it's much simpler to just say that the guest should stop referring >>> to a8 surfaces if the client can't handle them. >> >> Not sure about that, this move might just shift the complexity from >> spice-server to the guest qxl driver. > > The ability to handle this is already pretty much present in at least > the X driver (and I'm pretty sure the Windows driver has it as well) > because any time something can't be expressed in the SPICE protocol, it > has to fall back to software rendering. Ie., it has to read all the > involved surfaces back from video memory, do software rendering, then > upload the result as an image. > > Dealing with a disappearing ability to handle a8 surfaces would simply > be a matter of reading back the a8 surfaces to guest RAM and then not > attempt to acccelerate any operations involving them any more. > > It looks much more involved to do it in spice-server because it would > probably involve adding a new concept of "emulated surface" that needs > to be handled specially in a bunch of cases. Ok, so the tradeoff seems clear. I trust you on that one, you know the guest drivers alot better than I do. Lets go forward with the client capability notification for the guest, /me awaits a new revision of the patches. cheers, Gerd