This sounds better (sorry, I'm not a developer): https://gitlab.freedesktop.org/wayland/wayland/-/issues/59 > However, Mesa also depends on wl_drm being exposed even if zwp_linux_dmabuf_v1 is being used. wl_drm also provides a device event, passing a DRM FD from compositor to client, so the client can infer additional placement parameters. For instance, if Mesa is rendering on a different GPU than the compositor is using for its rendering, then it must make sure the memory is accessible between devices, e.g. being placed in GTT space rather than hidden dedicated VRAM. https://wayland.freedesktop.org/architecture.html > The open source stack uses the drm Wayland extension, which lets the client discover the drm device to use and authenticate and then share drm (GEM) buffers with the compositor. This gets the device fd via [wl_drm](https://github.com/mesa3d/mesa/blob/master/src/egl/wayland/wayland-drm/wayland-drm.xml) listener (wl_drm_add_listener) and creates gbm_create_device from it: https://github.com/anderco/simple-gbm/blob/4b663ecc4caabd6679a1dcea02ef86eae8e2e041/simple-gbm.c#L162 https://github.com/XQuartz/xorg-server/blob/039d68238de67af9db46b6dbc919955a1c6a0467/hw/xwayland/xwayland-glamor-gbm.c#L732
Bug 1588904 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This sounds better (sorry, I'm not a developer): https://gitlab.freedesktop.org/wayland/wayland/-/issues/59 > However, Mesa also depends on wl_drm being exposed even if zwp_linux_dmabuf_v1 is being used. wl_drm also provides a device event, passing a DRM FD from compositor to client, so the client can infer additional placement parameters. For instance, if Mesa is rendering on a different GPU than the compositor is using for its rendering, then it must make sure the memory is accessible between devices, e.g. being placed in GTT space rather than hidden dedicated VRAM. https://wayland.freedesktop.org/architecture.html > The open source stack uses the drm Wayland extension, which lets the client discover the drm device to use and authenticate and then share drm (GEM) buffers with the compositor. This gets the device fd via [wl_drm](https://github.com/mesa3d/mesa/blob/master/src/egl/wayland/wayland-drm/wayland-drm.xml) listener (wl_drm_add_listener) and then uses it with `gbm_create_device(simple_gbm->fd)`: https://github.com/anderco/simple-gbm/blob/4b663ecc4caabd6679a1dcea02ef86eae8e2e041/simple-gbm.c#L162 https://github.com/XQuartz/xorg-server/blob/039d68238de67af9db46b6dbc919955a1c6a0467/hw/xwayland/xwayland-glamor-gbm.c#L732
This sounds better (sorry, I'm not a developer): https://gitlab.freedesktop.org/wayland/wayland/-/issues/59 > However, Mesa also depends on wl_drm being exposed even if zwp_linux_dmabuf_v1 is being used. wl_drm also provides a device event, passing a DRM FD from compositor to client, so the client can infer additional placement parameters. For instance, if Mesa is rendering on a different GPU than the compositor is using for its rendering, then it must make sure the memory is accessible between devices, e.g. being placed in GTT space rather than hidden dedicated VRAM. https://wayland.freedesktop.org/architecture.html > The open source stack uses the drm Wayland extension, which lets the client discover the drm device to use and authenticate and then share drm (GEM) buffers with the compositor. This gets the device fd via [wl_drm](https://github.com/mesa3d/mesa/blob/master/src/egl/wayland/wayland-drm/wayland-drm.xml) listener (wl_drm_add_listener) and then uses it with `gbm_create_device(simple_gbm->fd)`: https://github.com/anderco/simple-gbm/blob/4b663ecc4caabd6679a1dcea02ef86eae8e2e041/simple-gbm.c#L162 https://github.com/freedesktop/xorg-xserver/blob/5dc16f6fec672c10fc26dcaaf00df0f6bed0ef9a/hw/xwayland/xwayland-glamor-gbm.c#L755
This sounds better (sorry, I'm not a developer): https://gitlab.freedesktop.org/wayland/wayland/-/issues/59 > However, Mesa also depends on wl_drm being exposed even if zwp_linux_dmabuf_v1 is being used. wl_drm also provides a device event, passing a DRM FD from compositor to client, so the client can infer additional placement parameters. For instance, if Mesa is rendering on a different GPU than the compositor is using for its rendering, then it must make sure the memory is accessible between devices, e.g. being placed in GTT space rather than hidden dedicated VRAM. https://wayland.freedesktop.org/architecture.html > The open source stack uses the drm Wayland extension, which lets the client discover the drm device to use and authenticate and then share drm (GEM) buffers with the compositor. This gets the device fd via [wl_drm](https://github.com/mesa3d/mesa/blob/master/src/egl/wayland/wayland-drm/wayland-drm.xml) listener (wl_drm_add_listener) and then uses it with `gbm_create_device(simple_gbm->fd)`: https://github.com/anderco/simple-gbm/blob/4b663ecc4caabd6679a1dcea02ef86eae8e2e041/simple-gbm.c#L162 https://github.com/freedesktop/xorg-xserver/blob/5dc16f6fec672c10fc26dcaaf00df0f6bed0ef9a/hw/xwayland/xwayland-glamor-gbm.c#L755 On X11 (bug 1580166 comment 5) it works similar: Get [drm_fd](https://github.com/TexasInstruments/dri3wsegl/blob/2d8f701ebe429b0625f9523778dddc65b8593e85/dri3test.c#L633) with [dri3_open()](https://github.com/TexasInstruments/dri3wsegl/blob/2d8f701ebe429b0625f9523778dddc65b8593e85/dri3test.c#L371) and use it with [gbm_create_device()](https://github.com/TexasInstruments/dri3wsegl/blob/2d8f701ebe429b0625f9523778dddc65b8593e85/dri3test.c#L206).