On 11/14/2017 10:33 AM, Gerd Hoffmann wrote:
Hi,
[ Cc'ing David Airlie and Marc-André Lureau ]
Lets step back and look at the problem you are trying to solve.
It seems you want guest wayland applications appear seamless on the host
wayland server, correct?
Correct.
How does the wayland rendering workflow look like? As far I know the
wayland protocol doesn't include any rendering. Rendering happens
client side, into some buffer (one per window), which is then passed to
the server for display compositing. Correct? So you basically want
pass that buffer from guest to host?
Correct.
What kind of shared memory is used by wayland?
sysv shm? gbm buffers / dmabufs?
Typically, shared memory for CPU-rendered content, and dmabufs for
GPU-rendered content.
Ok. I guess solving this for virtio-gpu (with virgl enabled) is easiest
then. Due to opengl rendering being offloaded to the host gpu the
guest window content already is in a host gpu buffer.
Yes, besides, we already have virtio-gpu in place which can be improved
as needed.
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".
Thanks,
Tomeu
So we "only" need to export that buffer as dmabuf and pass it to the
wayland server. That still doesn't look trivial though. qemu must
manage the dmabufs, so it must be involved somehow; a direct guest
client -> host server wayland connection (alone) will not work.
I think we need either a wayland proxy in qemu which rewrites the buffer
references, or the host wayland server must talk to both guest client
(vsock could work for that) and qemu (for dmabuf management). Or some
mixed model, such as a separate wayland proxy server talking to qemu for
dmabuf management.
I suspect in any case we need a wayland protocol extension for a new
buffer type as passing buffer references from guest to host can't use
filehandles.
cheers,
Gerd
