[Spice-devel] [RFC PATCH v2 00/20] Monitor ID rework

[Gerd Hoffmann]

> > > Now I'm mostly guessing here, but from what I understand, we could send
> > > the frames of multiple monitors in sync over a single display channel,
> > > but if we use multiple channels, they are not synchronized and would
> > > arrive rather arbitrarily on the client?
> > 
> > With a single channel it is easier to syncronize them, yes.
> > 
> > Right now qxl has two types of surfaces.  Primary (the actual display)
> > and non-primary (basically pixel data storage).  Spice ops can (among
> > other 2d ops) blit data from one surface to another.  So you can store
> > the content of a window in a surface, then blit it to primary to draw
> > the window.  This was state of the art roughly 15 years ago, when qxl
> > was designed.
> > 
> > These days nobody uses 2d ops any more.  Compositors use the 3d engine
> > (or llvmpipe in case there is no 3d hardware) to render the desktop to a
> > framebuffer.  Then they ask the gpu to flip to that framebuffer on the
> > next vblank interval.  While the first framebuffer is shown they render
> > the next frame to second framebuffer, then flip again so the two
> > framebuffer swap roles.
> > 
> > I think we can support this in spice/qxl this way:
> > 
> >   (1) Drop the concept of a "primary" surface (except for backward
> >       compatibility of course).
> >   (2) Allow to map any surface to any monitor (i.e. "please display
> >       surface 17 on monitor 1").
> > 
> > Workflow would look like this then:
> > 
> >   (1) userspace creates a drm framebuffer
> >   (2) qxl driver defines a surface for it.
> >   (2) userspace renders into the framebuffer.
> >   (3) userspace asks qxl to show that framebuffer.
> >   (4) qxl will send updates for that framebuffer to spice-server.
> >   (5) qxl will send monitor map request for that framebuffer to
> >       spice-server.
> > 
> > The same will work just fine for two monitors.  And given that qxl will
> > first send the bulky updates for both framebuffers and then flip both
> > with a small map request command syncronization should not be a big
> > issue.  If needed it should be possible to explicitly group the map
> > requests, or have a single message which sets the map for all monitors
> > of the channel.
> 
> Ok, this is for the qemu <-> spice server interface. For the network
> protocol, spice server <-> client, there needs to be something too.

Yes, sure.  Should look very simliar as most of the qxl device
operations map directly to spice display channel messages.

> That's mainly what I was referring to in the previous email. On a
> single channel, I think synchronization can work and may be easy.
> Inbetween channels, I think it will be a challenge.

Yes.  Not sure what the state of mm timer is.  In the past that was used
to sync between display channel and sound channel, dunno whenever that
is still the case.

> Also, in another email you suggested using virtio-gpu instead of QXL
> for wayland. Is virtio-gpu the modern successor of QXL?

It is a newer display device with a newer design.  So some of the issues
qxl has are gone.  virtio-gpu doesn't provide any 2d ops, but they are
increasingly unused by modern guests aynway.  virtio-gpu can optionally
offers 3d support, there is a mesa driver for it.

> If so, why not just use that for wayland and leave QXL for xorg only?

That certainly is an option.  Also note that wayland on qxl works fine
in single-head mode.

> (The only issue I can see is if someone wants to switch xorg/wayland
> sessions.)

xorg works on virtio-gpu, including multihead support with the help of
vdagent.

cheers,
  Gerd