(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:
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.
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:
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
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 ).
KDE, X11, Debian Testing:
$ xdpyinfo | grep DRI
XWayland is DRI3-only.
Use the dri3 and present extension directly. The dri3 extension can give us the DRM render node.
From 2013: https://lwn.net/Articles/569701/ + https://keithp.com/~keithp/talks/xdc2013-dri3.pdf