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