> > On 12 October 2017 at 19:16, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > On Fri, 2017-10-06 at 12:40 +0200, Gerd Hoffmann wrote: > >> Hi, > >> > >> > Would not actually be possible to detect a destroy + create > >> > commands and avoid having to change any version/driver? > >> > >> Well, that would be option (3) of the original mail: Make the spice > >> client hide this. Basically not go into "no display" mode instantly > >> after destroy-surface, but wait a bit to see whenever it is followed > >> by > >> a create-surface command. > > > > Ping. What do you think? > > We are fixing it host side, I still think we need hack the guest until it > knows > the host has the workaround, > > Daniel Vetter suggested we take a different path for atomic page flip, and > put back the copy mechanism until we can support atomic modesetting properly, > which might be simpler than reverting all the qxl atomic work. > > Dave. > I read the entire thread on https://bugzilla.kernel.org/show_bug.cgi?id=196777 so, somebody changed the driver introducing this bug. So, by definition the fix should be in kernel (VM). I honestly don't think that any workaround is a good way to go. Simply we want to do a new thing that was not planned (atomic page flipping), the current QXL protocol requires a destroy+create on surface 0 which is the primary. Changing host (Qemu or spice-server) is an update and as Justin pointed out is a bad idea to require an user to update the host in order to update the VM. Changing client is a workaround but does not seem so easy to do, I mean users uses different clients packages in different way (Windows, RHV, virt-viewer). Accepting the limitation that this workaround can bring I personally would like to have some opinion on some spice-gtk guy on what they think. How long this could require to be implemented? Is an easy workaround to maintain or requires so much changes that is not worth? About my suggestion on create+destroy detection I was suggesting more of a spice-server change. I remember (I'm getting older) that on the old VGA all you have to do for page flipping was to change a register stating the start of video memory. X had Xmouse and panning, you could have a large video and see a small portion (never saw nobody using this but was cool). As I said I think requiring destroy before create is not really good. I was discussing this with Christophe Fergeau when I fixed some bugs on surface handling. But changing this (allowing create without destroy first) is changing an improper/undefined behaviour to a defined one that is a protocol (QXL) change, and as such should be declared to VM. About multiple primary (visible on output) surfaces maybe is a good idea on QXL protocol, no idea how this could fit in all design (like monitors config). Current monitors config (both QXL and network) has a surface_id so seems to indicate that this can be used for output. How this is handled by all components and if can be easily extended I have no idea. In the network protocol any surface can be primary, in server code it must be surface 0 which actually cannot be secondary. Frediano _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel