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): compiz-0.3.4-2.fc7 How reproducible: Run compiz on a host with the nvidia drivers and start half a dozen copies of glxgears. 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 machine: --- 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. Felix
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.
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 : http://www.nvnews.net/vbulletin/showthread.php?t=77030 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp