[Spice-devel] qxl and page flip

[Gerd Hoffmann]

  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