With the recent versions of Mesa it is possible to use --disable-glx --disable-opengl and possibly some others configure options (--without-dri-drivers) in order to build Mesa without "desktop" OpenGL support. Why on earth would anyone want to disable OpenGL in Mesa on a normal desktop system? There are a bunch of ARM devices with the graphics accelerators which only support OpenGL ES (mostly closed source, but the reverse engineered open source drivers are quickly progressing). Developing and testing OpenGL ES compatible software is easier when we have no OpenGL available. Reproducible: Always Steps to Reproduce: 1. Set "-opengl egl gles gles1 gles2" USE flags in /etc/make.conf 2. Rebuild the system Actual Results: Mesa still gets built with OpenGL support. There are OpenGL headers and libraries in the system. Expected Results: Only EGL/GLES should be supported in the system. Any 3D applications, which are not OpenGL ES compliant, should obviously fail either at the build time or when executed. It is already possible to use /etc/portage/env/media-libs/mesa to add EXTRA_ECONF with the needed configure options, but a native OpenGL-free configuration would be very much welcome.
Similar to bug 447664 comment 6, this would require changes to eselect opengl first.
(In reply to Chí-Thanh Christopher Nguyễn from comment #1) > Similar to bug 447664 comment 6, this would require changes to eselect > opengl first. eselect-opengl can already handle this, it is just necessary to create "/usr/lib/opengl/xorg-x11/.gles-only" file to indicate that libGL.so is not provided. However of course a lot of userland applications have major problems with GLES compatibility and very few of them work out of the box (Qt5 and its demos, Kwin compositing window manager, glmark2-es2). Linaro/Ubuntu has some patches for a number of packages which have never reached upstream and this shows. Cleaning up all this mess may take time.
Also bug 447664 comment 6 evaluates the possibility of providing symlinks to libGL.so from mesa. In my opinion that's a way to hide problems instead of fixing them. If somebody somehow gets a proprietary libGLESv2.so blob and libGL.so from mesa linked into the same binary at the same time, this may cause various spurrious failures. Preferably the offending packages should fail at compile time, so that we get a chance to fix them and have a healthier system in the long run. Surely the software emulated OpenGL also has some value for some users (just to be able to run some application no matter the performance penalty). But this IMHO should be handled by the selection of USE flags.
A bad news ("Mesa (9.0): configure.ac: Allow OpenGL ES1 and ES2 only with enabled OpenGL"): http://lists.freedesktop.org/archives/mesa-dev/2013-February/033909.html http://lists.freedesktop.org/archives/mesa-commit/2013-February/041708.html Apparently upstream does not want to support this configuration, it was only available in some Mesa 9.x snapshots (which I happened to be using) and did not last long. Still there does not seem to be any clear technical reason other than reducing the maintenance burden by dropping something that they consider to be not really important.
It looks to me like this patch was not intended for master, but got pulled in anyway.
Sent a question to the mesa-dev mailing list: http://lists.freedesktop.org/archives/mesa-dev/2013-August/042840.html
(In reply to Chí-Thanh Christopher Nguyễn from comment #5) > It looks to me like this patch was not intended for master, but got pulled > in anyway. According to http://lists.freedesktop.org/archives/mesa-dev/2013-February/034048.html this patch was approved with "Mesa shouldn't allow users to shoot themselves in the foot so easily" review. Maybe they can change their mind though?
Need to fix this upstream first.
