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

[Lukáš Hrázký]

On Tue, 2018-08-28 at 15:46 +0200, Gerd Hoffmann wrote:
> > > > Ok, that makes some sense. You do however need some synchronization
> > > > mechanism between the different framebuffers? (Imagine a video playing
> > > > across two displays)
> > > 
> > > The linux kernel kms drivers support atomic page flips for both
> > > displays, and wayland actually uses that.
> > 
> > Ok, what about the SPICE case? If we use one surface per display, we
> > also need some sort of synchronization mechanism.
> > 
> > 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.
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.

Also, in another email you suggested using virtio-gpu instead of QXL
for wayland. Is virtio-gpu the modern successor of QXL? If so, why not
just use that for wayland and leave QXL for xorg only? (The only issue
I can see is if someone wants to switch xorg/wayland sessions.)

> cheers,
>   Gerd
>