(Robert Mader [:rmader] from bug 1619523 comment 11) > I also gave this a look today and if I understand things correctly, all possibilities to go forward here require some serious effort. That is assuming the goal is shipping things enabled by default - because everything else I'd consider wasted time. > - use EGL with DMABUF: EGL facilitates things quite a bit, but what's missing is GBM support on X11. So we'd need to reimplement things that are much easier on Wayland + potential bugs in drivers IIUC. No NVidia support, i.e. we'd only target platforms that could as well use Wayland. I'm not a developer, but I searched a bit for GBM on X11: https://www.raspberrypi.org/forums/viewtopic.php?t=250271#p1527921 > DRM supports a single client at a time. If X is running then it is the one true client, and anything else will be told permission denied. This is expected. > If you wish to run within X then you need to look at composing via EGL, not via GBM/DRM. Legacy DRI2: https://eleni.mutantstargoat.com/hikiko/2013/05/28/gbm-and-x-2/ > To create a GBM buffer you first need to create a drm device and then use its device descriptor to create a gbm device. To do this under X you need a way to tell xserver which device you use to avoid permission issues. I made a GitHub-wide search for above "gbm_create_device xcb_dri2_authenticate" and found an old Mozilla repository: https://github.com/pcwalton/linux-drm-sharing-test > This is a demonstration of how to use cross-process texture sharing using DRI/DRM directly on Linux. The client process (`drm-client`), which is intended to have lower privileges, does not need an X connection; you can see the resources that it is using with `strace`. > > Be warned that, because we are using DRI2, the `drm-client` can access all publicly accessible GPU buffers in the system. This should be fixed with DRI3, which uses file descriptors instead of global names (see [1]). KDE, X11, Debian Testing: ``` $ xdpyinfo | grep DRI DRI2 DRI3 ``` XWayland is DRI3-only. DRI3: https://github.com/swaywm/wlroots/issues/1352 > X11 > Use the dri3 and present extension directly. The dri3 extension can give us the DRM render node. https://github.com/TexasInstruments/dri3wsegl/blob/2d8f701ebe429b0625f9523778dddc65b8593e85/dri3test.c https://github.com/iXit/wine-nine-standalone/blob/bf71ae00220265749cc6af1e1e81f5b287891e0a/d3d9-nine/dri3.c
Bug 1580166 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.
(Robert Mader [:rmader] from bug 1619523 comment 11) > I also gave this a look today and if I understand things correctly, all possibilities to go forward here require some serious effort. That is assuming the goal is shipping things enabled by default - because everything else I'd consider wasted time. > - use EGL with DMABUF: EGL facilitates things quite a bit, but what's missing is GBM support on X11. So we'd need to reimplement things that are much easier on Wayland + potential bugs in drivers IIUC. No NVidia support, i.e. we'd only target platforms that could as well use Wayland. I'm not a developer, but I searched a bit for GBM on X11: https://www.raspberrypi.org/forums/viewtopic.php?t=250271#p1527921 > DRM supports a single client at a time. If X is running then it is the one true client, and anything else will be told permission denied. This is expected. > If you wish to run within X then you need to look at composing via EGL, not via GBM/DRM. Legacy DRI2: https://eleni.mutantstargoat.com/hikiko/2013/05/28/gbm-and-x-2/ > To create a GBM buffer you first need to create a drm device and then use its device descriptor to create a gbm device. To do this under X you need a way to tell xserver which device you use to avoid permission issues. I made a GitHub-wide search for above "gbm_create_device xcb_dri2_authenticate" and found an old Mozilla repository: https://github.com/pcwalton/linux-drm-sharing-test > This is a demonstration of how to use cross-process texture sharing using DRI/DRM directly on Linux. The client process (`drm-client`), which is intended to have lower privileges, does not need an X connection; you can see the resources that it is using with `strace`. > > Be warned that, because we are using DRI2, the `drm-client` can access all publicly accessible GPU buffers in the system. This should be fixed with DRI3, which uses file descriptors instead of global names (see [1]). KDE, X11, Debian Testing: ``` $ xdpyinfo | grep DRI DRI2 DRI3 ``` XWayland is DRI3-only. DRI3: https://github.com/swaywm/wlroots/issues/1352 > X11 > Use the dri3 and present extension directly. The dri3 extension can give us the DRM render node. https://github.com/TexasInstruments/dri3wsegl/blob/2d8f701ebe429b0625f9523778dddc65b8593e85/dri3test.c https://github.com/iXit/wine-nine-standalone/blob/bf71ae00220265749cc6af1e1e81f5b287891e0a/d3d9-nine/dri3.c From 2013: https://lwn.net/Articles/569701/ + https://keithp.com/~keithp/talks/xdc2013-dri3.pdf