Hi, > > 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. > 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. Correct. Fundamentally still the same on modern hardware. Ironically pageflip works better with stdvga and spice. When running non-qxl display adapters spice-server doesn't know where the guest video memory is. qemu hands a scratchpad buffer to spice-server as primary surface backing storage, then sends QXL_DRAW_COPY commands for display updates. So guests can pageflip and spice-server doesn't even know this happened. The problem we have with qxl is that spice-server needs to know where the video memory is, for lazy (local) rendering. In most cases the local rendering never happens because it is not needed. Thats why the framebuffer blit hack sort-of works: In theory spice-server's local rendering executing the blit could overwrite the guests framebuffer, but in practice only the spice client actually runs the blit command in the vast majority of cases. Switching the qxl kms driver to use a scratchpad model too should be easy for userspace apps not using qxl ioctls (i.e. basically everything but xorg-x11-drv-qxl). Just use the vga memory region (start of pci bar 0) as scratchpad, then we can safely use framebuffer blits for display updates. The tricky part here is to not break xorg-x11-drv- qxl. > 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. Yes. When adding page flip support I'd likewise do it rather explicit. New qxl pci revision indicating support, new qxl command (or flag) for the guest to request this. > 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. Yes, in theory. Big question is whenever this is implemented correctly everywhere, given that the code likely has never seen a surface_id != 0. > In the network protocol any surface can be primary, in > server code it must be surface 0 which actually cannot be > secondary. The qxl kms driver registers all framebuffers as secondary anyway. The currently visible one is configured as primary in addition, so it actually has two ids, 0 and the real one ;) cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel