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

[Gerd Hoffmann]

  Hi,

(can't answer all spice questions, but parts of this with some qemu
background).

> Scan-out is a terminology quite similar to the old frame buffer, right?
> I think is meant to distinguish buffers to hold texture or other 3d stuff
> and buffers rendered to a screen.

Yes.

> I imagine the SCANOUT is sent on client connection or when resolution
> change.

Also when the backing store changes (i.e. page-flip).

> 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.

> 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.

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.

> If Linux drm dma buffers are not strictly bound to (e)GL perhaps we could
> avoid the use of gl in the names.

Well, host side handling of the dma-bufs requires opengl even if the
guest does 2d rendering only.  So the naming makes sense to me.

> I was also wondering if instead of passing just some fixed attributes and
> then build the attribute list for eglCreateImageKHR we could pass a similar
> set of attribute-type+attribute to be extensible.
> Specifically I was thinking about the possible usage of the offset attribute
> in a 2d context sharing the frame buffer.

Sounds sensible to me.

> What will happen if a client try to connect from a remote machine?
> A normal video stream is automatically used?

Idea is to feed the dma-bufs into gpu-assisted video encoder, then send
over H.264[1] to remote.  I think there is no code yet, not fully sure
though.

cheers,
  Gerd

[1] Or whatever the hardware is able to encode, unfortunately hardware 
    support for free formats seems to be rare / non-existing ;(