Created attachment 800902 [details, diff] Patch for missing __driDriverGetExtensions_i915c symbol I've been trying to get media-libs/mesa-amber working on an older laptop and ran into a few issues. First of all, it seems the only way to get a system to actually use the installed libraries of the media-libs/mesa-amber package is with a couple environment variables: __GLX_VENDOR_LIBRARY_NAME MESA_LOADER_DRIVER_OVERRIDE The first one, __GLX_VENDOR_LIBRARY_NAME, doesn't seem to have any official documentation other than the libglvnd code that actually uses it[1] and various forum posts[2]. 1) https://gitlab.freedesktop.org/glvnd/libglvnd/-/blob/master/src/GLX/libglx.c 2) https://forums.gentoo.org/viewtopic-t-1152344.html, https://bbs.archlinux.org/viewtopic.php?id=275808 The second, MESA_LOADER_DRIVER_OVERRIDE, is documented on the mesa website[1]. 1) https://docs.mesa3d.org/envvars.html For my laptop I'm using the following: __GLX_VENDOR_LIBRARY_NAME="amber" MESA_LOADER_DRIVER_OVERRIDE="i915c" The above are set via a new file called /etc/env.d/99mesa-amber-env. The first, __GLX_VENDOR_LIBRARY_NAME, does force the system to use libGLX from the amber package (eg /usr/lib/libGLX_amber.so.0.0.0). However, I had to patch media-libs/mesa-amber to get the second one, MESA_LOADER_DRIVER_OVERRIDE, to work. A patch is required because the existing media-libs/mesa-amber ebuild renames /usr/lib/dri/i915_dri.so to /usr/lib/dri/i915c_dri.so, which breaks the file and symbol naming convention expected by the mesa driver loader code. When MESA_LOADER_DRIVER_OVERRIDE="i915c" is used without my patch, the driver cannot be loaded. By adding the additional environment variable LIBGL_DEBUG="verbose" the following info is reported: MESA-LOADER: dlopen(/usr/lib/dri/i915c_dri.so) MESA-LOADER: driver does not expose __driDriverGetExtensions_i915c(): /usr/lib/dri/i915c_dri.so: undefined symbol: __driDriverGetExtensions_i915c MESA-LOADER: dlopen(/usr/lib/dri/swrast_dri.so) What that says is that mesa is expecting to find a symbol in the driver file that matches its name, __driDriverGetExtensions_i915c, and when it doesn't it aborts the loading of that file and defaults to swrast_dri.so. I managed to address this by creating a patch which adds that missing symbol, __driDriverGetExtensions_i915c, see attached. The patch just clones the code for the _driDriverGetExtensions_i915 symbol. The patch would have been simpler had I just renamed _driDriverGetExtensions_i915 to _driDriverGetExtensions_i915c, but I wasn't sure if there would be any implications to that. Might it make sense to create an ebuild to includes the above mentioned work arounds?
Interesting, thanks for testing. You appear to be the first person to have tried it :)
I was bit by this as well. Thanks for investigating and fixing! In the end, I returned to llvmpipe since the i915 only supports OpenGL 1.3 and some software just doesn't work with that :/
I also stumbled over this issue when I tried to use mesa-amber for my older laptop in the kitchen. It has an old Intel 855GM chipset, but still useful for browsing websites, writing emails or listening music on Spotify. Rebuilding mesa-amber with the provided patch applied, and adding there two environment variables has also fixed it for me. Works like a charm now. I'm wondering why these changes didn't made it into the portage already? However, many thanks for tracking this issue down. Regards, Marco
Has the patch been sent upstream anywhere?
I have not attempted to upstream the patch. Actually, I'm not sure that would be appropriate. If the media-libs/mesa-amber ebuild hadn't renamed the .so file the bulk (all?) of the patch would not be required. I understand from the comment in the ebuild that the renaming was done to avoid a comflict with media-libs/mesa:0, but I never understood was why both packages need to be installed. I never had a chance to dig into that and was hoping the original creator of the media-libs/mesa-amber ebuild might shed some light on that.
Exactly, the problem is caused by the renaming done in mesa-amber to avoid conflicts with the i915g driver that is still in upstream mesa (i915c supports gen2-3; i915g supports only gen3, so they're not interchangeable). > # Move i915_dri.so -> i915c_dri.so to not conflict with media-libs/mesa:0. > for dridir in "${ED}"/usr/lib*/dri; do > if [[ -e ${dridir}/i915_dri.so ]]; then > mv ${dridir}/i915{,c}_dri.so || die > fi > done The patch is probably the right thing to do.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=01cb5b2658d9421ab5a35e6a36c29e305e68c8f4 commit 01cb5b2658d9421ab5a35e6a36c29e305e68c8f4 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2023-05-12 17:37:34 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2023-05-12 17:38:25 +0000 media-libs/mesa-amber: Fix loading i915c driver Thanks to Allan Mondor <bugs.gentoo@acmondor.ca> for the patch. Closes: https://bugs.gentoo.org/866425 Signed-off-by: Matt Turner <mattst88@gentoo.org> media-libs/mesa-amber/files/mesa-amber-i915c.patch | 46 ++++++++++++++++++++++ ...r-21.3.9.ebuild => mesa-amber-21.3.9-r1.ebuild} | 4 ++ 2 files changed, 50 insertions(+)
