Messages in this thread | | | Date | Mon, 12 Feb 2018 16:29:03 +0100 | From | Gerd Hoffmann <> | Subject | Re: [PATCH v3 1/2] drm/virtio: Add window server support |
| |
> > I was more thinking about a struct containing enough info to allow the > > proxy on the host side find the buffer, something like: > > > > struct { > > enum type { stdvga, virtio-cpu, ... } > > pcislot device; > > union { > > int stdvga_pcibar_offset; > > int virtio_gpu_resource_id; > > } > > } > > > > So when the guest proxy gets a message with a fd referencing a buffer it > > would have to figure where the buffer is, rewrite the message into the > > struct above for the host proxy. The host proxy would rewrite the > > message again for the server. > > What I don't understand yet is how we can keep the buffer descriptions > together with the protocol data that references them. > > With SCM_RIGHTS, the FDs are placed in the ancillary data that "travels" > together with the protocol data that references them.
Place the buffer description into the wayland extension protocol messages?
i.e. have some wl_virt_proxy protocol extension. Then, for the stdvga case:
(1) client sends wl_drm/create_prime_buffer request to the guest proxy (2) guest proxy rewrites this into wl_virt_proxy/create_buffer, or maybe a create_stdvga_buffer request, carrying all the information listed above, and sends it to the host proxy. (3) host proxy rewrites it again into a wl_shm_pool/create_buffer and forwards it to the server.
cheers, Gerd
| |