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

[Marc-André Lureau]

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.


> > About the parameters that are currently used for the scan-out.
> > Beside width, height and stripe which are quite obvious.
> > fd points to a dma buffer exported by the Linux DRM layer.
> > format is specified as the format of fd data, as in your comment the fourcc
> > types, defined in drm_fourcc.h.
> > The extension for eglCreateImageKHR for this are specified at
> > www.kronos.org/registry/egl, EGL_EXT_image_dma_buf_import.
> > 
> > Can we export a dma_buf for normal 2d operations? Would it make sense to
> > use
> > the same protocol to share the 2d frame buffer between spice-server and the
> > client if the client is on the same machine?
> 
> 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)

> For spice it doesn't really make a difference, it just gets the dma-buf
> and doesn't need to worry whenever the guest runs in 2d or 3d mode.
> 
> How to handle qxl best is a open question.

It's fairly easy from server and client side to handle switching between the 2d/qxl and 3d/opengl context. However, if it makes more sense for qemu to do all with one or the other, it can be changed at qemu level. It is interesting to have the possibility to switch in the protocol in any case (as done today with wip qemu branch).

thanks