[Spice-devel] [PATCH v2 spice-protocol 2/2] Add unix GL scanout messages

[Marc-André Lureau]

Hi

----- Original Message -----
> On Do, 2015-12-17 at 06:34 -0500, Marc-André Lureau wrote:
> > Hi
> > 
> > ----- Original Message -----
> > > > What happen with multiple monitors? Is it just not supported or a
> > > > single
> > > > scan-out is used for multiple monitors? Would be sensible to add the
> > > > number
> > > > of the scan-out to support multiple monitors?
> > > 
> > > Yes, I think we should add a scanout number here.
> > 
> > How whould that be compatible with the spice MonitorConfig messages? I
> > don't think it's necessary, and it could easily be added later if needed.
> 
> Ahem, scratch that.  MonitorConfig isn't going to fly with virtio-gpu
> (at least not with multiple heads defined that way).  With virtio_gpu we
> will have one display channel per head, so we can use the channel id to
> identify the scanout.

It's not so clear to me, it sounds like it would be more efficient/synchronized to have a single scanout, especially with a gl context. Even in this multiple scanout case, we can still use MonitorConfig to identify the display/monitor in the scanout, like we do with qxl. And I still don't understand the reason to have a scanout ID, if you have one scanout per channel.

> 
> > > qemu (with wip patches) can do that already, for non-qxl cards.  Guest
> > > renders into a simple framebuffer, qemu writes this into a opengl
> > > texture, exports the texture as dma-buf and hands over a handle.
> > 
> > I think his point was rather a similar message to share a simple shm
> > (non-dmabuf/gl)
> 
> Sure, we could create shm segments, then try using the X11 mit-shm
> extension to display without copying again.

Yeah, that already exists in client side at least, with some drawbacks (could be improved with proper cairo usage I believe). But anyway, I think this is different, and could use the existing 2d/surface/format/monitor messages with a small addition.

> But does it make sense with the world moving forward to opengl/wayland?
> It will be obsolete in a few years ...

That's what we said years ago, and it is still around. It may well survive just like the text console...