Chromium failing with: Drm prime capability is not supported

[elFarto]

I'm attempting to get my VA-API implementation working within Chromium, but I'm having a slight issue. When started under GNOME 42 with the --use-gl=egl parameter, Chromium prints the following error:

Drm prime capability is not supported

From what I can determine that error is because the capabilities field in the wl_drm extension is 0, and this is the library that's setting that value (I can't find anything in mutter related to it). Firstly, is this correct?

It seems Chromium with the EGL backend is relying on wl_drm to allocate buffers directly and pass them into VA-API. This is similar to Chromium on X11 with EGL which attempts to use DRI3 open to get the DRM device. Chromium's implementation is here.

My second question is: Can this be made to work? I'm not sure I fully understand why the wl_drm extension is implemented in EGL, but shouldn't it be possible to implement all of the wl_drm interface now that you have a GBM implementation?

[cubanismo]

With enough effort, you could probably implement more wl_drm support in egl-wayland. I implemented just enough of it (The part that advertises which device the wayland compositor is running on, a questionable concept) to get Xwayland running, because their was no available replacement for this concept at the time and it's what Xwayland required.

However, it's more a question of where your work is most productive. I'd argue you'd be better off updating Chromium to use linux_dmabuf protocols to handle buffer allocation/sharing, as later versions of that protocol completely supersede the functionality in wl_drm, and modernize it as well with support for the concepts DRM format modifiers and compositors that are aware of and make use of multiple GPUs beyond simple iGPU desktop + dGPU client app usage. See for example similar work NVIDIA is doing in Xwayland:

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/818

Chromium already seems to have some support for the dmabuf protocol here:

https://source.chromium.org/chromium/chromium/src/+/main:ui/ozone/platform/wayland/host/wayland_zwp_linux_dmabuf.cc

So it might just be a question of updating some higher level code to make use of the lower-level support, or perhaps VA-API itself is using wl_drm to share buffers with Chromium? I'm not that familiar with the broader stack here, so I can't give specific guidance beyond that.

In other words, I suppose I'm saying "patches welcome" on this one, but you're probably better off using another method.

[elFarto]

Ok, that explains why wl_drm feels a bit odd, and I agree that it would be better to update Chromium than update this library, I was just hoping to avoid rebuilding Chromium from source :smile:.

Poking around a bit more I did discover that VA-API is only enabled on X11 at the moment, the irony being that I was only using Wayland to test with as the X11 code path requires the DRI3 open method.

I guess I'll wait for them to get Chromium VA-API support working on Wayland before I try getting my library working.

Thanks for your assistance.

[ghost]

This is why Firefox's DRM I think is superior.