Gerd Hoffmann <kraxel@xxxxxxxxxx> writes:
>> 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.
I think the same scheme as for commands could be used:
- When a new client connects, if it doesn't understand a8, then the
server won't send it any a8 surfaces.
- The guest driver is expected to not refer to any such surfaces once
it sees the change in capability bits, and may want to delete them.
The race condition is handled by the server processing all commands
after changing the capability bits, but before forwarding any commands
to the new client.
If I don't hear any objections to the above, I'll update the patches as
follows:
- When a new client connects, the capability bits are changed,
followed by a processing of all commands in the ring. At this
point new commands may be forwarded.
- Add ifdefs to allow qemu to compile against older versions of
spice.
- Use 4 for the PCI revision instead of 5
I'll drop the NUM_SURFACES change for now. The guest driver probably
need the ability to swap pixmaps in and out of video memory in any case,
since X clients sometimes leak pixmaps and since no fixed number of
surfaces is likely to be enough for all cases.
Søren
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel