[Spice-devel] [RFC PATCH v2 00/20] Monitor ID rework

[Gerd Hoffmann]

  Hi,

> > > Having a single frame buffer for channel is a current implementation
> > > limit which can be relaxed.
> > 
> > But I don't think this is possible without changing spice protocol and
> > qxl device.  Which opens the question whenever this is worth the trouble
> > or whenever we should just use virtio-gpu instead.
> 
> The idea would be to remove a implementation limit on the SPICE
> protocol to allow this.  Does not require QXL change

Hmm, why?  I fail to see the point given that qxl wouldn't be able to
use it unless you change it too, and all other qemu display devices are
either single-head anyway (stdvga, cirrus, ...) or use one channel per
head.

> although the QXL change would help with Wayland and the bug you
> mentioned.

Yes.  I think it would also allow spice protocol changes which are more
useful long-term.

> But honestly it seems to me that almost all the recent bugs with QXL
> driver are due to not wanting to update the QXL device but at the same
> time wanting to update the QXL Linux driver adding feature so ending
> up using complicate code to implement workarounds. And every time we
> keep saying "is not worth" and we continue making the driver more
> buggy and complicated.

qxl got atomic mode setting support.  Yes, there was some fallout from
that.  And, yes, due to qxl not having real page-flip support we have
have to play some tricks here.

Sure, we can change the qxl device to support pageflip.  And while being
at it we can also add support for multiple outputs with a single device
(using one framebuffer/surface per output).

The fundamental issue is the concept of the "primary surface" which
combines defining a surface and defining an output into a single
operation.  These need to be separated, so there isn't any special
surface.  And any existing surface can be mapped to the output.  Then
qxl can pageflip by just mapping a different surface.

When allowing multiple outputs per device you can do screen mirroring by
just mapping the same surface to multiple outputs, very simliar to how
things work on real hardware.

And maybe cursors should just be surfaces too.

Note that this wouldn't make the qxl guest driver less complex because
we want guests being able to run on old qxl versions without pageflip
support too.

Also note that virtio-gpu has all that today.  So the alternative to all
that would be to just recommend virtio-gpu for guests running wayland.
Wayland does software rendering into a dumb drm buffer and will not use
any of the qxl 2d ops anyway (and I suspect modern xorg/windows doesn't
use much of it either), so there isn't much of a difference between qxl
and virtio-gpu ...

> We are trying too but this discussion has been going on for months before
> agreeing that we prefer to break a bit compatibility instead of trying
> to wrap around our mind with complicated code doing weird assumptions
> and keeping adding new assumptions.
> 
> The protocol implementation is accumulating many limitation and bugs
> which start to be a bit too costly to maintain, I think the cost of
> backward compatibility is less than all these complications.

Possibly.  Didn't follow spice-devel that closely, and also had a bunch
of sommer vacation PTO weeks recently.  So sorry for coming late to the
party.

Is there a high-level overview of the changes planned?  For starters I'm
mostly interested in spice-protocol and qxl guest interface changes.  We
need to get the concepts right before implementing the stuff.  And I
think its easier if we bundle the changes into one protocol update
instead of doing many small protocol changes.

thanks,
  Gerd