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

[Frediano Ziglio]

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

To support streaming of multiple outputs with a single SPICE channel.

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

I would say the opposite, that SPICE changes would allow some long-term QXL
changes. Which changes do you have in mind?

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

The result won't be different if you transform a video memory region
into a surface when you want to associate it with an output and will
easily allows to move drm buffer off/on video memory.

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

My experience with a "all or nothing" approach is that is never ending,
I think we want to release RHEL8 before 2021.

> thanks,
>   Gerd
> 
> 

Frediano