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. The nice thing about dma-bufs is that the size is fixed and the pages are pinned. Which should make it *alot* simpler to come up with a robust implement compared to something using shm_open() or memfd_create() filehandles. 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. cheers, Gerd
