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 ;(
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel