I'm opening this bug to track opinions and progress of changing the eselect-open{c,g}l as outlined in [1]. Some of you already seen it on IRC, and I have personally tested it with xorg-x11 <-> nvidia opengl switching. Though I have edited env.d files by hand, I don't have the eselect module written yet. What are your opinions? Do you foresee any problems? Otherwise, I will start working on the implementation. [1]:https://wiki.gentoo.org/wiki/User:MGorny/New_eselect-opengl_design
Things that you describe as current solution differs from things in my system. Can you explain what is wrong? I have nvidia-drivers, mesa and eselect-opengl installed. 'eselect opengl list' reports that nvidia implementation is selected. Any /usr/lib*/eselect/ directories are not exists, but there is file /etc/env.d/03opengl with the next content (also there is similar file for opencl): # Configuration file for eselect # This file has been automatically generated. LDPATH="/usr/lib32/opengl/nvidia/lib:/usr/lib64/opengl/nvidia/lib" OPENGL_PROFILE="nvidia" Drivers installed into /usr/lib*/opengl subdirectories: $ equery f media-libs/mesa | grep libGL.so$ /usr/lib64/opengl/xorg-x11/lib/libGL.so $ equery f x11-drivers/nvidia-drivers | grep libGL.so$ /usr/lib32/opengl/nvidia/lib/libGL.so /usr/lib64/opengl/nvidia/lib/libGL.so
(In reply to Alexander Turenko from comment #1) > Things that you describe as current solution differs from things in my > system. Can you explain what is wrong? A typo on my part. It was supposed to be /usr/lib*/opengl.
Uh, sorry, I realize: symlinks placed inside /usr/lib*/ directly as libGL*.so files, not it /usr/lib*/opengl. My inadvertence.
In section “The problem” you write “Driver providers also include their own versions of system headers”, but /usr/lib/opengl/nvidia/ have no 'include' directory and /usr/include/GL directory contain symlinks to xorg-x11 headers. Situation with ATI is differ? Anyway, I confused at compiling with one headers set and dinamic linking with another library. That look as not good approach, maybe even like hack. But I don’t know the situation about opengl drivers, maybe it’s best of a bad lot.
(CC-ing nvidia- and ati-drivers maintainers)
Sounds good. If you have a patch I could actually test this. :)
Good idea, I'll wrap up a poor man's patch soon :).
Created attachment 391122 [details, diff] 01-opengl-move.patch How to test it, poor man's way (before I rewrite eselect-opengl): cd $PORTDIR # assuming you fetched the patch into /tmp patch -p1 < /tmp/01-opengl-move.patch # FEATURES=-collision-protect needed, protect-owned is fine emerge -1v mesa xorg-server mv /etc/env.d/{03,000}opengl mv /tmp/20-eselect-opengl.conf /etc/X11/xorg.conf.d/ And restart X11. If you want to test xorg-x11 impl, comment out nvidia lines from the two /etc files. Reverting: rm /etc/X11/xorg.conf.d/20-eselect-opengl.conf mv /etc/env.d/{000,03}opengl rm $PORTDIR/media-libs/mesa/mesa-10.3.4-r1.ebuild rm $PORTDIR/x11-base/xorg-server/xorg-server-1.16.2-r1.ebuild emerge -1v mesa xorg-server Hope it's good enough for early testing. I will write the new eselect modules later.
Created attachment 391124 [details] 20-eselect-opengl.conf
@Prefix, could you take a look at this idea, please? That is, if it will work fine with all the fancy systems we try to support ;).
The OpenGL side of things seems to work splendidly with nvidia-drivers. OpenCL/EGL and other newfangled stuff I haven't tested yet.
(adding bugs that likely could be closed after the change)
OpenGL part committed, p.masked. I have no clue if we decide to do anything OpenCL, considering how screwed implementations are...
(In reply to Michał Górny from comment #13) > OpenGL part committed, p.masked. I have no clue if we decide to do anything > OpenCL, considering how screwed implementations are... nvidia-drivers installs : lrwxrwxrwx 1 root root 14 Nov 29 14:44 /usr/lib64/OpenCL/vendors/nvidia/libOpenCL.so -> libOpenCL.so.1 lrwxrwxrwx 1 root root 18 Nov 29 14:44 /usr/lib64/OpenCL/vendors/nvidia/libOpenCL.so.1 -> libOpenCL.so.1.0.0 -rwxr-xr-x 1 root root 21712 Nov 29 14:44 /usr/lib64/OpenCL/vendors/nvidia/libOpenCL.so.1.0.0 So it shouldn't be hard to set LDPATH the way eselect-opengl does.
Nothing generates or owns /etc/X11/xorg.conf.d, so without anything further you get: # eselect opengl set 1 Switching to nvidia OpenGL interface.../usr/share/eselect/modules/opengl.eselect: line 146: /etc/X11/xorg.conf.d/20opengl.conf: No such file or directory done
(In reply to Jeroen Roovers from comment #15) > Nothing generates or owns /etc/X11/xorg.conf.d, so without anything further > you get: > > # eselect opengl set 1 > Switching to nvidia OpenGL > interface.../usr/share/eselect/modules/opengl.eselect: line 146: > /etc/X11/xorg.conf.d/20opengl.conf: No such file or directory > done Fixed in 1.3.1.
One more note: the current thing doesn't really support 32-bit from-source builds with emul-linux-x86. You need full multilib for that. To fix it, we'd have to re-release emul- sets which I don't think we want to do. But we may want the while and unmask it along with multilib packages.
Doesn't work for me with mesa-9999::x11 and eselect-opengl-1.3.1. Getting this in terminal for e.g. xbmc: libGL error: unable to load driver: i965_dri.so libGL error: driver pointer missing libGL error: failed to load driver: i965 And sw driver is used by DE (usable only with gallium: eselect mesa 64bit sw 2). Note that there was 03opengl file in my /etc/env.d, no idea which script generated it, but I deleted it since eselect opengl wasn't touching it. ~ # equery f media-libs/mesa | grep libGL.so$ /usr/lib32/libGL.so /usr/lib64/libGL.so ~ # equery f x11-drivers/nvidia-drivers | grep libGL.so$ /usr/lib32/opengl/nvidia/lib/libGL.so /usr/lib64/opengl/nvidia/lib/libGL.so ~ # eselect opengl list Available OpenGL implementations: [1] nvidia [2] xorg-x11 * ~ # cat /etc/X11/xorg.conf.d/20opengl.conf Section "Files" ModulePath "/usr/lib32/xorg/modules" ModulePath "/usr/lib64/xorg/modules" EndSection ~ # cat /etc/env.d/000opengl # Configuration file for eselect # This file has been automatically generated. LDPATH="/usr/lib64/opengl/xorg-x11/lib" OPENGL_PROFILE="xorg-x11" ~ # ls /usr/lib64/opengl/xorg-x11/lib ls: cannot access /usr/lib64/opengl/xorg-x11/lib: No such file or directory
(In reply to Reinis Danne from comment #18) > Note that there was 03opengl file in my /etc/env.d, no idea which script > generated it, but I deleted it since eselect opengl wasn't touching it. Btw newer eselect-opengl ebuild removes ${EROOT}/etc/env.d/02opengl file. Should it be 03opengl?
(In reply to nE0sIghT from comment #19) > (In reply to Reinis Danne from comment #18) > > Note that there was 03opengl file in my /etc/env.d, no idea which script > > generated it, but I deleted it since eselect opengl wasn't touching it. > > Btw newer eselect-opengl ebuild removes ${EROOT}/etc/env.d/02opengl file. > Should it be 03opengl? Thanks for noticing this :). + 17 Dec 2014; Michał Górny <mgorny@gentoo.org> eselect-opengl-1.3.0.ebuild, + eselect-opengl-1.3.1.ebuild: + Remove correct old file, reported by nE0sIghT.
(In reply to Reinis Danne from comment #18) > Doesn't work for me with mesa-9999::x11 and eselect-opengl-1.3.1. Getting > this in terminal for e.g. xbmc: > libGL error: unable to load driver: i965_dri.so > libGL error: driver pointer missing > libGL error: failed to load driver: i965 > > And sw driver is used by DE (usable only with gallium: eselect mesa 64bit sw > 2). > > Note that there was 03opengl file in my /etc/env.d, no idea which script > generated it, but I deleted it since eselect opengl wasn't touching it. Sorry I'm replying this late. Is this still a problem? After you get 03opengl removed, you should env-update, then logout and login again to get the environment cleaned up.
(In reply to Michał Górny from comment #21) > (In reply to Reinis Danne from comment #18) > > Doesn't work for me with mesa-9999::x11 and eselect-opengl-1.3.1. Getting > > this in terminal for e.g. xbmc: > > libGL error: unable to load driver: i965_dri.so > > libGL error: driver pointer missing > > libGL error: failed to load driver: i965 > > > > And sw driver is used by DE (usable only with gallium: eselect mesa 64bit sw > > 2). > > > > Note that there was 03opengl file in my /etc/env.d, no idea which script > > generated it, but I deleted it since eselect opengl wasn't touching it. > > Sorry I'm replying this late. Is this still a problem? After you get > 03opengl removed, you should env-update, then logout and login again to get > the environment cleaned up. Not a problem anymore. Had to reboot several times and fiddle with eselect modules and then it started magically working (still no idea what made it work) even tough 000opengl still points to non-existing directory.
Am I correct in my assumption that this would not let one compile against the headers and libraries provided by third-party OpenGL (ES) solutions? If so, this should never become mainline. It not, how would I let ebuilds compile against third party opengl packages with this implementation? Reverted to mesa-10.3.5 and eselect-opengl-1.2.6 for the time being.
1 Applications are to be built against Xorg implementations of the OpenGL/OpenCL interfaces, 2. eselect-opengl should only switch the implementations used at runtime. From the Wiki. This is plain horrible. I am running an ARM system with Mali blobs. I _cannot_ compile against Mesa headers/libraries. They differ. This is flawed by design.
(In reply to Wilhelm Eger from comment #23) > Am I correct in my assumption that this would not let one compile against > the headers and libraries provided by third-party OpenGL (ES) solutions? If you have a binary package that replaces media-libs/mesa, there should be no need to switch between implementations as long as the headers and libraries are in the right places.
(In reply to gentooer from comment #24) > 1 Applications are to be built against Xorg implementations of the > OpenGL/OpenCL interfaces, > 2. eselect-opengl should only switch the implementations used at runtime. > > From the Wiki. This is plain horrible. I am running an ARM system with Mali > blobs. I _cannot_ compile against Mesa headers/libraries. They differ. > > This is flawed by design. Are you sure about that or just rage-guessing? The OpenGL* headers are defined by Khronos, so even if they differ the core should be compatible. So I'd really appreciate if you elaborated instead of offending our efforts.
