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

[Frediano Ziglio]

> On Fri, Aug 24, 2018 at 09:16:09AM -0400, Frediano Ziglio wrote:
> > > 
> > > On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> > > > > Yes, we want this for sure.  One channel per display.
> > > > 
> > > > For sure? This deserves a justification.
> > > 
> > > That is the way modern display architectures (including wayland) are
> > > working.  One framebuffer per display.  Not one huge framebuffer
> > > covering all heads, then defining rectangles for each display, like qxl
> > > handles multihead on linux (with xorg).
> > > 
> > > And the qxl way of doing multihead on linux starts to cause problems:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1611141
> > > 
> > 
> > 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 although the QXL change would
help with Wayland and the bug you mentioned. 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.

> > I agree the main problem of this rework should be vdagent "mapping"
> > of the display_id received although honestly as we are changing the
> > protocol for different reasons I would remove the ugly formula and
> > all its subtle assumptions all the way around.
> 
> If we absolutely have to touch the mouse messages anyway, then yes, lets
> make this explicit.  But having two mouse message versions comes with
> costs in terms of maintainance and backward compatibility, so I'd try to
> stick to the existing message.
> 
> cheers,
>   Gerd
> 

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.
The old client can't support the codecs and many bugs requires some huge
updates anyway so pretending to use old clients with new VMs is
IMHO insanely time consuming, better try to fix these design problems
instead.

Frediano