[Spice-devel] qxl and page flip

[Frediano Ziglio]

> 
> On 12 October 2017 at 19:16, Gerd Hoffmann <kraxel at redhat.com> 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