Bug 219545 - aiglx-defaults patch breaks nvidia
aiglx-defaults patch breaks nvidia
Product: Fedora
Classification: Fedora
Component: compiz (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kristian Høgsberg
Depends On:
  Show dependency treegraph
Reported: 2006-12-13 16:26 EST by Felix Bellaby
Modified: 2008-05-06 21:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 21:03:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
rpmlint of installed compiz package for fc6 x86_64 (3.53 KB, text/plain)
2007-07-28 10:33 EDT, Nicolas Chauvet (kwizart)
no flags Details

  None (edit)
Description Felix Bellaby 2006-12-13 16:26:35 EST
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):


How reproducible:

Run compiz on a host with the nvidia drivers and start half a dozen copies of

Actual results:

The whole desktop becomes extremely slow and may even seem to freeze. 

Expected results:

The glxgears apps will run happily at about 60% of the speed obtained with xcompmgr.

Additional info:

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;
 #ifdef USE_COW
@@ -95,10 +95,13 @@
            "[--refresh-rate RATE]\n       "
            "[--fast-filter] "
            "[--indirect-rendering] "
+           "[--direct-rendering]\n       "
            "[--strict-binding] "
-           "[--replace]\n       "
+           "[--xgl-binding] "
+           "[--test-mode]\n       "
+           "[--replace] "
            "[--sm-disable] "
-           "[--sm-client-id ID] "
+           "[--sm-client-id ID]\n       "
            "[--no-detection] "
            "[--version]\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.

Comment 1 Felix Bellaby 2006-12-14 11:10:58 EST
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
from git.

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.
Comment 2 Kristian Høgsberg 2007-04-16 13:44:58 EDT
All these issues should be fixed with compiz-0.3.6-8.fc7.
Comment 3 Nicolas Chauvet (kwizart) 2007-07-28 10:32:02 EDT
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...

Comment 4 Nicolas Chauvet (kwizart) 2007-07-28 10:33:12 EDT
Created attachment 160161 [details]
rpmlint of installed compiz package for fc6 x86_64
Comment 5 Bug Zapper 2008-04-03 14:47:41 EDT
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.
Comment 6 Bug Zapper 2008-05-06 21:03:12 EDT
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:

Note You need to log in before you can comment on or make changes to this bug.