Anyone using media-libs/mesa-amber? [solved]

[acmondor]

I have a machine with an old 915GM graphics controller which is no longer supported by current versions of media-libs/mesa. Apparently support for older hardware was dropped in mesa 22.0.0 and moved to the "amber" branch, which is available in portage as the relatively new media-libs/mesa-amber package. I was able to emerge that package but can't seem to make it work. The machine behaves as though that package is not there and the net effect is that the kde desktop is useless. Just hovering the mouse over the Application Menu icon cause the desktop to crash.

When I remotely connect to this machine via ssh I can see that the /usr/lib/dri/i915_dri.so from media-libs/mesa-22.0.5 gets loaded at runtime instead of /usr/lib/dri/i915c_dri.so from media-libs/mesa-amber-21.3.9. So, there must be something to missing give preference to the drivers in media-libs/mesa-amber.

When I revert back to media-libs/mesa-21.3.7, the last version that worked on this machine, everything is fine. However, the only way to get back to that version was by putting a copy of the ebuild for that version in a local overlay and it's probably just a matter of time before something breaks with that approach.

Please let me know if you got media-libs/mesa-amber working.

Thanks.

[torrunes]

The subject has been quiet for a month, so I am just "pinging" by confirming that you are not alone. I have some Atom-based installations that stopped working properly, and experience the same as you.

Before digging deeper into the issue, it would be nice if anyone had some knowhow to share first

[fredbear5150]

I posted a similar question on here a few weeks ago without a definitive answer but I think I have found a solution.

I've been messing around with an old IBM Thinkpad G40 laptop that has an Intel 855GM graphics adapter that has

[acmondor]

fredbear5150,

I finally had a chance to try your suggestion. With the "export __GLX_VENDOR_LIBRARY_NAME=amber" in place I did see /usr/lib/libGLX_amber.so.0.0.0 being loaded instead of /usr/lib/libGLX_mesa.so.0.0.0, but I did not solve my original problem. What it did do, at least originally, was to make the look of the plasmashell worse (eg borders of the widgets were ugly broken lines).

The original problem I'm trying to solve is /usr/bin/plasmashell crashing. With the latest mesa installed when the mouse is moved over the plasmashell bar (eg hover over one of the quick launch icons) the /usr/bin/plasmashell crashes in about a second or two. I have captured a stack traceback of the crash and it points to /usr/lib/dri/i915_dri.so, whether mesa-amber is installed or not. I've had similar crashes over the years with various versions of mesa, but I never actually captured a stack trace until now.

The file /usr/lib/dri/i915_dri.so is from media-libs/mesa and there is an equivalent file in media-libs/mesa-amber, which is /usr/lib/dri/i915c_dri.so. I assume the 'c' in the name stands for the older classic driver. What's required is a way for the latter to be loaded. The GLX export doesn't do it.

I just did a quick hack and I manually replace with /usr/lib/dri/i915_dri.so with /usr/lib/dri/i915c_dri.so and that solved the plasmashell crashes. Also, when using /usr/lib/dri/i915c_dri.so via this rename hack it does not seem to matter which libGLX, mesa or amber, is used. The plasmashell looks fine with either one and glxgears provides the same frame as I had with mesa-21.3.7 (about 60 FPS).

Last, but not least, if I use the above mentioned hack to get plasmashell to load i915c_dri.so, I can later undo that hack and run glxgears which picks the original /usr/lib/dri/i915_dri.so and it works find. This suggests if the bug is an issue with mesa, it may be one that is fixable in the latest version. Or it just may even be a bug of some sort in the plasmashell. Eitherway, it suggests I may not need mesa-amber at all for my laptop.

Anyway, reqardless of finally outcome for my laptop it seems to me that GLX environment setting should somehow be made part of the mesa-amber ebuild, perhaps via /etc/env.d like many other ebuilds do already.

[acmondor]

I finally managed to mesa-amber working. Details on the work arounds required are captured in https://bugs.gentoo.org/866425