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

[Gerd Hoffmann]

On 08/29/12 02:58, Søren Sandmann wrote:
> Gerd Hoffmann <kraxel at redhat.com> writes:
> 
>> On 08/27/12 19:20, Søren Sandmann Pedersen wrote:
>>> From: Søren Sandmann Pedersen <ssp at redhat.com>
>>>
>>> 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?

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

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