Re: [Qemu-devel] [Spice-devel] [PATCH] Add new client_present and client capabilities fields to QXLRom

[sandmann@cs.au.dk (Søren Sandmann)]

Gerd Hoffmann <kraxel@redhat.com> writes:

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

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.


Søren