I tried to run compiz today with the new nvidia beta drivers since they now support tfp. The problem i had was that compiz would always link to /usr/lib64/opengl/xorg-x11/lib/libGL.so.1 and would not link to /usr/lib64/opengl/nvidia/lib/libGL.so.1 as it should on my system. I had to pull compiz from git and compile it to get it working. The result of this problem is that compiz can't bind to texture and would display a white cube.
*** Bug 148675 has been marked as a duplicate of this bug. ***
The only method to resolving this is to build upon the /usr/lib/libGL.so.1 instead of the mesa provided one. To do this --with-gl-libs needs to be removed from the ebuild. I am not sure how the intel and ati side works. Also if you are using compiz either way, I think you need to pass: --use-cow to the compiz binary when running it so that it does not kill itself with the white screen (which is where the cannot bind to texture errors come from).
In my case, compiz was working fine until a couple days ago it showed the white cube. I tried downgrading mesa (which I updated 3 days ago) but that didn't help. What's the difference between libGL.so in /usr/lib and the one from mesa?
Well ... I removed the --with-gl-libs from the ebuild, and it didn't change a thing. As I'm using DRI with the i915 driver, /usr/lib/libGL.so just points to /usr/lib/opengl/xorg-x11/lib/libGL.so I guess the libGL from fglrx or nvidia must have "something" the mesa one doesn't. Back to square one for me ...
Remi: That shouldn't be the case (the /usr/lib/opengl...-path in libGL.la), we've fixed that a while back. Which mesa version are you using?
The one from portage on my laptop (6.5.1-r1) and the one from dberkholz's overlay (-git) on my duron/r300 which shows identical results.
You need to set your OpenGL implementation properly. eselect opengl list eselect opengl set <value from list>
This is related to bug #149069. One of them should really be a dup. Hanno, it's your choice.
That still doesn't fix it for me as I only have one opengl implementation on both my laptop and my desktop (xorg-x11). The mistery remains ...
*** Bug 149069 has been marked as a duplicate of this bug. ***
Since #149069 got marked as a dup to here... I think I should mention that Nvidia says you should not run compiz with indirect-rendering... http://www.nvnews.net/vbulletin/showthread.php?t=77030
wolf31o2@inertia ~ $ cat `which startcompiz` # Start window decorator gnome-window-decorator --replace & # Start compiz compiz --replace --use-cow --strict-binding gconf wolf31o2@inertia ~ $ emerge -vp nvidia-drivers compiz These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-1.0.9625 USE="dlloader" 0 kB [ebuild R ] x11-wm/compiz-0.0.13_pre20060921 USE="dbus svg" VIDEO_CARDS="nvidia" 0 kB [1] Total size of downloads: 0 kB Portage overlays: [1] /usr/local/portage wolf31o2@inertia ~ $ /usr/sbin/lspci | grep VGA 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 110M / GeForce Go 7300 (rev a1) The compiz I am using has my patch from bug #149069 applied to it.
it now links to the libGL in /usr/lib, which will break xgl (that we don't support yet, but anyway, some people need it) thus I've added an additional compiz-xgl startscript setting the correct ldpath. For nvivia-users: Please try compiz-nvidia startscript and report back to me if it works.
