Red Hat Bugzilla – Bug 219545
aiglx-defaults patch breaks nvidia
Last modified: 2008-05-06 21:03:14 EDT
Description of problem:
The nvidia driver support for direct rendering under compositing only works
correctly when the GL compositor uses direct rendering. The aiglx-defaults.patch
in the compiz rpm turns off direct rendering and leaves the user with no means
of turning it back on (the documented --direct-rendering option is not
implemented in the code).
Version-Release number of selected component (if applicable):
Run compiz on a host with the nvidia drivers and start half a dozen copies of
The whole desktop becomes extremely slow and may even seem to freeze.
The glxgears apps will run happily at about 60% of the speed obtained with xcompmgr.
The following replacement for the aiglx-defaults.patch gets things working on my
--- compiz-0.3.4/src/main.c.aiglx-defaults 2006-11-11 18:11:36.000000000 +0000
+++ compiz-0.3.4/src/main.c 2006-12-13 20:54:39.000000000 +0000
@@ -79,7 +79,7 @@
Bool replaceCurrentWm = FALSE;
Bool indirectRendering = FALSE;
-Bool strictBinding = FALSE;
+Bool strictBinding = TRUE;
Bool noDetection = FALSE;
@@ -95,10 +95,13 @@
"[--refresh-rate RATE]\n "
+ "[--direct-rendering]\n "
- "[--replace]\n "
+ "[--xgl-binding] "
+ "[--test-mode]\n "
+ "[--replace] "
- "[--sm-client-id ID] "
+ "[--sm-client-id ID]\n "
I have not been able to test the effects of setting indirectRendering=FALSE on
an aiglx machine, but I see no reason why it should not work as compiz has this
setting in git and no one has reported any problems.
The aiglx-defaults.patch contains another oddity. It sets strictBinding to TRUE,
but does not offer the user any means of changing it to FALSE.
This is less of a problem because strictBinding=TRUE is a good thing for the
nvidia drivers as well as aiglx. However, there might still be some users
(people using Xgl ?) who would like to be able to change it back to the default
Perhaps a patch to the options code so that users can successfully specify
--no-strict-binding, --direct-rendering and --indirect-rendering would be useful?
My comments in the main bug report act on the assumption that aiglx will still
work if the compositor requests a direct context. If this is not the case then a
patch to main.c to check whether compiz is running under aiglx would be an
extremely useful addition to the ability to specify --direct-rendering. The
value returned by strncmp (glXGetString (GL_VENDOR), "NVIDIA", 6) would suffice
to identify the nvidia drivers, but something more sophisticated might be
required to exactly identify when aiglx is available.
All these issues should be fixed with compiz-0.3.6-8.fc7.
Can you backport thoses changes for fc6 also?
I (and lot of nvidia users with >=100.xx.xx ) have experienced problems with
0.3.6-2.fc6 (and possibly fc7 version also...)
While shutdown or compiz de-activation, the Xorg freezes and it only possible to
kill it, using ssh if possible... Nvidia have tips to work with compiz: see :
Having compiz using cow by default seems a good way to have it work on nvidia's...
Actually, the same problem appear with beryl if users do not set: using
composite extention (cow)"... If this options is set, everything is good...
Also there is some problem with compiz package, (see attachement), rpath is
usally forbidden ldconfig is missing at postin postun, and shlibs problem are
usualycaused by some missing LDFLAGS while linking...
Created attachment 160161 [details]
rpmlint of installed compiz package for fc6 x86_64
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.
If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.
The process we're following is outlined here: