egl-wayland 1.1.9 & gbm & xwayland

[tgurr]

While things appear to work fine for a KDE plasma session (after having added the qtwayland patch from https://codereview.qt-project.org/c/qt/qtwayland/+/373473) started via sddm the same can't be said about xwayland/opengl.

I tried a few combinations of the json files shipped by nvidia-drivers 495.29.05 (and mesa) and I also included the following xwayland patches, one of them being mentioned in the release notes http://us.download.nvidia.com/XFree86/Linux-x86_64/495.29.05/README/gbm.html.

https://cgit.freedesktop.org/xorg/xserver/commit/hw/xwayland?id=f15729376d7c7ef183bd8f77156c281ff84c2bd9 https://cgit.freedesktop.org/xorg/xserver/commit/hw/xwayland?id=5daf42b48924b1e93d4fe40e600c42ae9835712f

With the combination of

/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json
/usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json
/usr/share/glvnd/egl_vendor.d/10_nvidia.json
/usr/share/glvnd/egl_vendor.d/50_mesa.json

and/or

/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json
/usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json
/usr/share/glvnd/egl_vendor.d/10_nvidia.json

I get the following glxinfo output: glxinfo_all_json.txt

and the error message

$ glxinfo
libGL error: MESA-LOADER: failed to open nouveau: /usr/x86_64-pc-linux-gnu/lib/dri/nouveau_dri.so: cannot open shared object file: No such file or directory (search paths /usr/x86_64-pc-linux-gnu/lib/dri, suffix _dri)
libGL error: failed to load driver: nouveau

With

/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json
/usr/share/glvnd/egl_vendor.d/10_nvidia.json
/usr/share/glvnd/egl_vendor.d/50_mesa.json

I get no error message and the following output: glxinfo_15_nvidia_gbm.json.txt

And with just

/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json
/usr/share/glvnd/egl_vendor.d/10_nvidia.json

things appear to work correctly, but I guess not using the gbm path but the old way of just eglstream? glxinfo output: glxinfo_nvidia_json_only.txt

[tgurr]

I think I found the problem, when explicitly passing GBM_BACKEND=nvidia-drm __GLX_VENDOR_LIBRARY_NAME=nvidia I got the error message

MESA-LOADER: failed to open nvidia-drm: /usr/x86_64-pc-linux-gnu/lib/gbm/nvidia-drm_gbm.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden (search paths /usr/x86_64-pc-linux-gnu/lib/gbm, suffix _gbm)

Looks like the default search path by mesa for the gbm backends is $libdir/gbm which can be controlled by the meson option gbm-backends-path on compile time. We don't touch this option yet, hence it doesn't search in $libdir directly which was the location I installed the nvidia-drm_gbm.so symlink to. After creating $libdir/gbm and the symlink things started to work as expected. Note I don't run the nvidia-installer but have our distribution package installing the required files for nvidia-drivers.

What is the default location the installer installs nvidia-drm_gbm.so to? Should we rather adjust our mesa package to also search in $libdir in addition to $libdir/gbm?

[cubanismo]

The installer creates a symlink from $libdir/gbm/nvidia-drm.so -> $libdir/libnvidia-allocator.so.. I wouldn't recommend deviating from the Mesa standard search path in your Mesa packaging unless really necessary. The default path was chosen to mirror, e.g., the DRI driver loader behavior, which looks in $libdir/dri IIRC.

I'm curious why this appeared to be specific to Xwayland usage though. I would think without this file in the correct path, kwin wouldn't be using the GBM path either.

[tgurr]

Thanks for the detailed explanation, we don't plan to deviate from standards and I just fixed our nvidia-drivers package to install the symlink to the correct location. I was just curious as the .manifest didn't give me any hint regarding the symlink pointing to gbm/ like there is for other stuff e.g.

libvdpau_nvidia.so 0000 VDPAU_SYMLINK NATIVE / vdpau/libvdpau_nvidia.so.495.29.05 MODULE:vdpau

so I somehow expected to find something similiar for nvidia-drm_gbm.so or the gbm documentation and hence my mistake in the first place. Thanks again for your help & time, greatly appreciated!

I have no idea in regards to kwin, but maybe because kwin already knew nvidia requires a special path and fell back to eglstream instead of gbm? Actually still now I have no idea how to check if kwin actually makes use of the gbm path or still uses eglstream but for xwayland/opengl stuff it was obvious that something is not working as expected.

[cubanismo]

I believe the path is implied by the type field, which should be GBM_BACKEND_LIB_SYMLINK if I remember correctly.

Yes, the native wayland client code will happily render using dma-buf or streams to a compositor using streams, and doesn't itself rely on GBM, so it's likely you're still using the streams path in the compositor. Patched Xwayland will prefer GBM over streams I believe.

Regardless, sounds like everything is working more or less as intended, so marking this issue resolved.