On 11/16/2017 11:49 AM, Gerd Hoffmann wrote:
Hi,
I'm more worried about CPU-rendered buffers, as the client is just putting
in the socket the output of shm_open or similar. There I don't see any easy
solution which is why I tried to get more "creative".
Will clients actually use cpu rendering of opengl is available?
Can clients cpu-render into dumb drm buffers?
For the sake of moving forward, let's assume for now that wl_shm clients
will be rendering to buffers allocated by VGEM or virtio-gpu. How would the
client in the guest be communicating that to the compositor in the host?
Export the drm buffer as dma-buf, then pass that.
I thought of SCM_RIGHTS on AF_VSOCK, which would return BADF if a FD is
passed that cannot be shared in the requested direction. Are there any
better options?
When limiting this SCM_RIGHTS support to dma-bufs, guest -> host, that
could actually work.
Would you go with SCM_RIGHTS as defined for AF_UNIX, or with a
different, more specific name?
The nice thing about dma-bufs is that the size is
fixed and the pages are pinned.
Those pages are permanently pinned? Would have expected to be only
pinned while scanning out, and such.
Which should make it *alot* simpler to
come up with a robust implement compared to something using shm_open()
or memfd_create() filehandles.
Guess some Wayland proxy in the guest will need to intercept SHM buffers
and copy them to virtio-gpu buffers then.
Hopefully at a later point we can do without those copies somehow.
So, guest vsock driver would import the dma-buf and send the scatter
list associated with the dma-buf over to the host. host vsock driver
has the guest memory map (like all vhost drivers), so it should be able
to create a dma-buf on the host side and pass it on to the host process.
When the process releases the dma-buf notify the guest driver that it
can drop its dma-buf reference.
Looks doable, also generic enough that it could be useful for more than
just seamless wayland support.
Thanks,
Tomeu
