i want to add a new ebuild for mali prebuilt userland GL libs ./usr/lib/libEGL.so ./usr/lib/libEGL.so.1 ./usr/lib/libEGL.so.1.0.45 ./usr/lib/libGLESv1_CM.so ./usr/lib/libGLESv1_CM.so.1 ./usr/lib/libGLESv1_CM.so.1.0.45 ./usr/lib/libGLESv2.so ./usr/lib/libGLESv2.so.2 ./usr/lib/libGLESv2.so.2.0.45 ./usr/lib/libmali.so ./usr/lib/libmali.so.0 ./usr/lib/libmali.so.0.0.45 what would be the best place for this ? media-libs/mali-drivers-bin ? how do i get integration with eselect-opengl ? i'll also need to add to add an ebuild for xf86-video-armsoc: http://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git but that won't be a big deal
To make eselect opengl recognize this, move lib{EGL,GL*,OpenVG}{,core}.{so,dylib,a} to /usr/lib/opengl/${NAME}/
Hey Spanky, Are these specific to the Exynos Mali, or do they work for... other hardware? I'm assuming Exynos specific, but I was more asking out of curiosity. Luca had put our binaries into x11-drivers in the EfikaMX overlay, but if media-libs is better, I just might do that for the updates we hope to push out soon.
it should work for Mali-T604 parts, but exynos5 is the only one i've tested (as it's the only one i have)
Okay, that's what I figured - I'm just wondering if we should name it something a bit more specific, since the Mali is used in a lot more than just Exynos, to possibly stave off bugs of "it doesn't work" - And I'm still not sure if they are better in media-libs or x11-drivers. I think, in the grand scheme of things it doesn't really matter, and leaving it in media-libs would make it easier for whenever Chromium syncs up.
these libs are the corollary to mesa. if these belong in x11-drivers/, then so does mesa. but i don't think either does as they aren't actual X11 drivers. in order to bring up an X server, you still need an X11 video driver e.g. x11-drivers/xf86-video-armsoc. as for different parts, i think we should start here and see where things go. in looking at the source code & build files that produced these libs, i don't see anything exynos specific in them. we take the ddk from arm and build it.
so mali doesn't provide libGL.so which causes eselect-opengl to complain should i cheat and symlink libGL.so from the mesa install (xorg-x11) ? or should we fix eselect-opengl to do use mesa as a base and symlink things out of there if the selected implementation doesn't provide replacements for everything ?
Yes, I see the same problem with raspberrypi-userland. Having eselect-opengl fall back to mesa's libGL is probably the best way. I imagine that some packages will fail to build when libGL.so is missing, but I have not verified that.
Note that the ebuild can do this already today by passing --ignore-missing to eselect opengl, but unsuspecting users will see an error message when they try to switch.
(In reply to comment #8) i am the unsuspecting user ;)
Created attachment 340226 [details] mali-drivers-bin-0.45-r96.ebuild - not tested I was given this, haven't had time to test (thanks steev though) :D
couple if's and oh's: - this thing should be named mali-libs (its egl lib not driver, driver is in kernel and its other story) - version should be matching interface version (eg. mali-r3p0-04rel0.tar.gz), as this requires same interface both on lib and on kernel counterpart (and its dependent on correct kernel support) and sloted for it too - this thing should go to media-libs as theres versions for: framebuffer, x11 and android (with eselect opengl you could get more than one), and provides egl acceleration for all of them (without X also) - this thing should go with correct headers for it (we could copy/patch current mesa ones with required changes if you want) - ebuild should be aware of libs abi (hardfloat/softfloat) - there are many software builds of mali-libs for specific product which vendor is supposed to supply (you don't know with what if any modifications vs arm source) and as such should go to overlay (i.e. chromium overlay) instead of portage - keep in mind this thing is proprietary software under unclear license As for changes in eselect-opengl, support for "lib{EGL,GL*,OpenVG,[Mm]ali,UMP}{,core}.{so,dylib,a}" would be nice (with removing old mali symlinks if they don't exist in opengl implementation when switching), also with support for non-standard headers (also removed when switching to opengl implementation that doesn't include them) side note: for mali 400 lib name is "libMali.so*" not "libmali.so*", also on mismatching kernel interface version this don't behave too sanely with mali400 my ebuild for mali400 attached below as reference
Created attachment 340492 [details] mali-libs-3_p0.ebuild
Created attachment 340494 [details] 99-mali-drivers.rules
Created attachment 340820 [details] mali-drivers-bin-0.45-r106.ebuild i've updated the public binary drop since the r96 version had TEXTRELs the $PV already reflects the version in the mali-ddk. this is the 0.45 release.
Steev, hows it going?
Mine is similar, although a bit more "in line" with what is expected of an eselect-enabled installation, the difference is that I don't install those mali-rules - this could be the reason why nerdboy has been having issues if so... Mine is also updated to the 1.2.0 release recently, although until more people have tested it, I would rather not move it into the tree.
Maybe it's not a blocker problem, but the "symlink everything (libEGL/libGLESv2/libGLESv1_CM) to a single libmali.so blob" approach used in mali-400 and mali-t6xx drivers is not really perfect. The problematic scenario is: 1. switch the opengl implementation from "xorg-x11" to "mali" 2. try to compile some GLESv2 application 3. which back to "xorg-x11" and try to run the compiled application (using Mesa softpipe/llvmpipe) 4. See that it fails to start because of unresolved symbols And ldd shows that the compiled binary happens to have only dependency on libEGL, but not on libGLESv2. On the other hand, the binaries compiled against "xorg-x11" implementation work fine for both "xorg-x11" and "mali" (and correctly list both libEGL and libGLESv2 as the shared library dependencies).
That may be a consequence of --as-needed so could be worked around by forcing --no-as-needed for applications building against mali-drivers-bin
I have no interest in proprietary drivers being under the x11@ umbrella.
we don't post X based libs anymore
