> 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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel