From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:43275)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1T6xOx-0005RB-6Q
	for qemu-devel@nongnu.org; Thu, 30 Aug 2012 01:34:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1T6xOw-0007Dk-AR
	for qemu-devel@nongnu.org; Thu, 30 Aug 2012 01:34:47 -0400
Received: from mx1.redhat.com ([209.132.183.28]:60773)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1T6xOw-0007Db-1w
	for qemu-devel@nongnu.org; Thu, 30 Aug 2012 01:34:46 -0400
Message-ID: <503EFB6D.1080701@redhat.com>
Date: Thu, 30 Aug 2012 07:34:37 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
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> <ye8wr0iecpl.fsf@llama11.cs.au.dk>
	<20120829101457.GC32547@garlic.redhat.com>
	<ye8k3whctg4.fsf@llama11.cs.au.dk>
In-Reply-To: <ye8k3whctg4.fsf@llama11.cs.au.dk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [Spice-devel] [PATCH] Add new client_present and
 client capabilities fields to QXLRom
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?ISO-8859-1?Q?S=F8ren_Sandmann?= <sandmann@cs.au.dk>
Cc: Alon Levy <alevy@redhat.com>, qemu-devel@nongnu.org, spice-devel@freedesktop.org, =?ISO-8859-1?Q?S=F8ren_Sandmann_Pederse?= =?ISO-8859-1?Q?n?= <ssp@redhat.com>

  Hi,

> The scheme I had in mind was this:
> 
>     - When a new non-a8-capable client appears, don't send it any of the
>       a8 surfaces
> 
>     - If the client doesn't understand a8 surfaces,
> 
>         - keep all a8 surfaces rendered on the server side
> 
>         - if the guest sends a command using an a8 surface as a
>           destination, simply render the command on the server side
> 
>         - if the client sends a command using an a8 surface as a source,
>           rewrite the image object to be a real image referring to the
>           server side bits (which are also sent or possibly cached)
>           rather than a surface

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.

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

cheers,
  Gerd