Created attachment 440473 [details] compiz screenshot Description of problem: reports "Accelerated 3D graphics is not available Desktop effects require hardware 3D support" when compiz is active and operational Version-Release number of selected component (if applicable): desktop-effects-0.8.7-2.fc14.x86_64 How reproducible: every time Steps to Reproduce: 1.select System>Preferences>Desktop Effects 2. 3. Actual results: see screenshot Expected results: the selection screen Additional info:
Please provide information about your graphics hardware and drivers, and attach (as an attachment) the output of glxinfo.
Created attachment 440547 [details] glxinfo
description: VGA compatible controller product: RV630 [Radeon HD 2600XT] vendor: ATI Technologies Inc xorg-x11-drv-ati-6.13.1-1.20100705git37b348059.fc14.x86_64 xorg-x11-server-common-1.9.0-1.fc15.x86_64 xorg-x11-server-Xorg-1.9.0-1.fc15.x86_64 desktop-effects-0.8.7-2.fc14.x86_64 mesa-libGL-7.9-0.6.fc14.x86_64 mesa-libGLU-devel-7.9-0.6.fc14.x86_64 mesa-libGLU-7.9-0.6.fc14.x86_64 mesa-libGL-devel-7.9-0.6.fc14.x86_64 mesa-dri-drivers-7.9-0.6.fc14.x86_64 mesa-dri-drivers-experimental-7.9-0.6.fc14.x86_64 compiz-fusion-extras-0.8.6-1.fc14.x86_64 compizconfig-backend-gconf-0.8.4-4.fc14.x86_64 compiz-fusion-unsupported-gnome-0.8.4-4.fc14.x86_64 libcompizconfig-0.8.4-3.fc14.x86_64 compiz-0.8.6-3.fc15.x86_64 compiz-fusion-unsupported-0.8.4-4.fc14.x86_64 compiz-fusion-0.8.6-1.fc14.x86_64 compiz-manager-0.6.0-10.fc12.noarch compizconfig-python-0.8.4-3.fc14.x86_64 compiz-fusion-extras-gnome-0.8.6-1.fc14.x86_64 compiz-gnome-0.8.6-3.fc15.x86_64 compiz-fusion-gnome-0.8.6-1.fc14.x86_64
(In reply to comment #2) > Created attachment 440547 [details] > glxinfo from F14 on same machine OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: Mesa DRI R600 (RV630 9588) 20090101 TCL DRI2 OpenGL version string: 2.0 Mesa 7.9-devel OpenGL shading language version string: 1.10
Created attachment 440550 [details] F14 glxinfo
On a couple of my (f14+rawhide mix) machines /dev/dri ends up with 0750 permissions and no acl for the current user, unlike /dev/dri/card0. Which can also lead to this. I haven't tracked what exactly changed in the kernel/udev/radon/mesa/consolekit setup that lead to this.
(In reply to comment #6) > On a couple of my (f14+rawhide mix) machines /dev/dri ends up with 0750 > permissions and no acl for the current user, unlike /dev/dri/card0. Which can > also lead to this. > I haven't tracked what exactly changed in the kernel/udev/radon/mesa/consolekit > setup that lead to this. Yes, permissions are 755 on /dev/dri on the working partition(F14) and they are 750 on rawhide
desktop-effects is perfectly right: OpenGL renderer string: Software Rasterizer Don't know why permissions on /dev/dri aren't right. Reassigning to ConsoleKit, which at least in the past used to set the perms there, according to consensus on #fedora-desktop.
[andrew@790x ~]$ rpm -qa|grep Console ConsoleKit-0.4.1-5.fc13.x86_64 ConsoleKit-libs-0.4.1-5.fc13.x86_64 ConsoleKit-x11-0.4.1-5.fc13.x86_64
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
could this possibly be a udev problem?
(In reply to comment #4) > (In reply to comment #2) > > Created attachment 440547 [details] [details] > > glxinfo > from F14 on same machine > OpenGL vendor string: Advanced Micro Devices, Inc. > OpenGL renderer string: Mesa DRI R600 (RV630 9588) 20090101 TCL DRI2 > OpenGL version string: 2.0 Mesa 7.9-devel > OpenGL shading language version string: 1.10 I just updated the above install to rawhide and now have [andrew@790x ~]$ glxinfo|grep OpenGL OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.9-devel OpenGL shading language version string: 1.20 OpenGL extensions: [andrew@790x dev]$ ls -al|grep dri drwxr-x---. 2 root root 80 Sep 4 15:29 dri
This cannot be a ConsoleKit bug because my ConsoleKit packages did not change, yet the permissions on /dev/dri did change.
(In reply to comment #13) > This cannot be a ConsoleKit bug because my ConsoleKit packages did not change, > yet the permissions on /dev/dri did change. It might be a change somewhere that causes ConsoleKit to set the wrong permissions. But udev is *not* responsible for setting the correct permissions here, ConsoleKit is, hence why assigning it to udev does not make much sense.
It's i's udev's udev-acl tool which adjusts the permissions properly. Reassigning.
(In reply to comment #15) > It's i's udev's udev-acl tool which adjusts the permissions properly. > Reassigning. Huh? not really... udev-acl sets ACL... not unix file modes. We might need a udev rules syntax for directory ownership and permission. It might be, that the kernel itself set the permission via devtmpfs.
Created attachment 443344 [details] boot.log for 2.6.36-rc3-dirty
Created attachment 443345 [details] boot.log for 2.6.36-0.16.rc3.git0
Created attachment 443346 [details] dmesg for 2.6.36-rc3-dirty
Created attachment 443347 [details] dmesg for 2.6.36-0.16.rc3.git0
Created attachment 443348 [details] 2.6.36-rc3-dirty .config
I just compiled an upstream kernel that sets the proper permissions on /dev/dri I have attached the boot.log and dmesg files along with the .config for the working kernel. Among the notable differences were a)2.6.36-rc3-dirty b)2.6.36-0.16.rc3.git0 a)Starting udev: Starting Huge Pages File System... OK b)Starting udev: udevd[419]: matchpathcon(/dev/hugepages) failed a)dracut: Loading SELinux policy dracut: /sbin/load_policy: Can't load policy: No such device b)dracut: Loading SELinux policy type=1404 audit(1283772614.398:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
Furthermore, I just booted 2.6.35.4-12.fc14.x86_64 #1 SMP Fri Aug 27 07:45:05 UTC 2010 and the permissions are also set properly. So it is a kernel problem, no?
(In reply to comment #23) > Furthermore, I just booted 2.6.35.4-12.fc14.x86_64 #1 SMP Fri Aug 27 07:45:05 > UTC 2010 and the permissions are also set properly. So it is a kernel problem, > no? looks like it
The problem seems to be in the .config of the latest kernels. I recompiled 2.6.36-0.18.rc3.git1 and the permissions are set properly I am attaching the .config that I used as config-2.6.36-0.18.rc3.git1.20100909se.fc15
Created attachment 446364 [details] working config for 2.6.36-0.18.rc3.git1
OK, I screwed up that previous kernel and selinux was disabled, but I made another one that works all around. [ats@asus ~]$ uname -a Linux asus 2.6.36-0.18.rc3.git1.20100909se2.fc15.x86_64 #1 SMP PREEMPT Thu Sep 9 15:54:22 CDT 2010 x86_64 x86_64 x86_64 GNU/Linux [ats@asus ~]$ sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 24 Policy from config file: targeted [ats@asus ~]$ glxinfo|grep OpenGL OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: Mesa DRI R600 (RV670 9501) 20090101 TCL DRI2 OpenGL version string: 2.1 Mesa 7.9-devel OpenGL shading language version string: 1.20 OpenGL extensions: [ats@asus ~]$ rpm -qa|grep selinux-policy selinux-policy-doc-3.9.3-3.fc15.noarch selinux-policy-targeted-3.9.3-3.fc15.noarch selinux-policy-mls-3.9.3-3.fc15.noarch selinux-policy-3.9.3-3.fc15.noarch selinux-policy-minimum-3.9.3-3.fc15.noarch
Created attachment 446378 [details] working config for 2.6.36-0.18.rc3.git1 with working selinux
*** Bug 633121 has been marked as a duplicate of this bug. ***
I was also experiencing this bug ( https://bugzilla.redhat.com/show_bug.cgi?id=634239 ,) before compiling my own kernels.
Created attachment 448563 [details] latest working config for 2.6.36-0.23
This difference may be enough. < # CONFIG_LOCKUP_DETECTOR is not set < # CONFIG_HARDLOCKUP_DETECTOR is not set > CONFIG_LOCKUP_DETECTOR=y > CONFIG_HARDLOCKUP_DETECTOR=y
(In reply to comment #32) > This difference may be enough. > < # CONFIG_LOCKUP_DETECTOR is not set > < # CONFIG_HARDLOCKUP_DETECTOR is not set > > CONFIG_LOCKUP_DETECTOR=y > > CONFIG_HARDLOCKUP_DETECTOR=y No makes no difference. This was to try and remedy https://bugzilla.redhat.com/show_bug.cgi?id=634239 not this bug anyway.
Just as an update, this is still happening on Rawhide for me today. kernel and udev versions running: kernel-2.6.36-0.32.rc6.git2.fc15.x86_64 udev-161-4.fc15.x86_64
(In reply to comment #34) > Just as an update, this is still happening on Rawhide for me today. kernel and > udev versions running: > > kernel-2.6.36-0.32.rc6.git2.fc15.x86_64 > udev-161-4.fc15.x86_64 I believe that it is a kernel problem, since the problem does not occur when booting a f14 kernel in Rawhide and it does occur when booting a Rawhide kernel in f14. I have not tried a kernel that I did not compile myself for quite awhile, I am using kernel-2.6.36-0.35.rc7.git0.20101006.fc15.x86_64 now. When the next version hits koji, I will try the standard version.
I have just tested kernel-2.6.36-0.39.rc8.git0.fc15.x86_64 and the problem persists. No problems with custom compiled kernels.
Definitely still happening for me too. I note that the /dev/dri and /dev/dri/* files are now set with the group 'video' instead of just root, but my user never is added to the video group by ConsoleKit. (I think that's how it's supposed to work. I lost track when people decided to redesign the Linux bootup/login system to require 37 daemons arbitrarily using umpteen different configuration file formats, almost none of which are documented thoroughly.)
(In reply to comment #37) > Definitely still happening for me too. I note that the /dev/dri and /dev/dri/* > files are now set with the group 'video' instead of just root, but my user > never is added to the video group by ConsoleKit. (I think that's how it's > supposed to work. I lost track when people decided to redesign the Linux > bootup/login system to require 37 daemons arbitrarily using umpteen different > configuration file formats, almost none of which are documented thoroughly.) It's _not_ done via groups and normal unix permissions! It's done via ACLs. $ getfacl /dev/dri/card0 # file: dev/dri/card0 # owner: root # group: video user::rw- user:harald:rw- <-------------------------- group::rw- mask::rw- other::---
The directory /dev/dri should have unix perms 0755, though!
Not to be overly annoying intentionally, but this is a particularly irritating bug and I just have no freaking clue how to fix it because I still have no idea how the 2010 flavor of the Linux/Fedora bootup sequence works. Is there some kind of quick-hack I can do that'll make it work other than just putting a chmod o+rwx /dev/dri in my rc.local ? (Or does rc.local not even work anymore? wouldn't surprise me.) If there's any more information I can provide to help identify the bug, I'm more than willing to provide it; just let me know what you need. Thanks.
I haven't tried a stock kernel since kernel-2.6.36-0.39, but my custom kernels have the permissions set properly. Have you tried to compile your own? I realize that this is not a proper solution, but since I compile my own kernels on other distros I already have configs that I know work good so it isn't such a big deal for me. I will attach my latest. If you add in your hardware you probably should be able to adapt it to work.
Created attachment 458912 [details] 2.6.36-1 config
dracut-008-0.10.gitb2415f4.fc15
Does not work for me. [ats@asus ~]$ glxinfo | grep OpenGL OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.10-devel OpenGL shading language version string: 1.20 OpenGL extensions: [ats@asus ~]$ ls -al /dev/dri ls: cannot open directory /dev/dri: Permission denied [ats@asus ~]$ sudo ls -al /dev/dri [sudo] password for ats: total 0 drwxr-x---. 2 root root 80 Nov 18 09:55 . drwxr-xr-x. 22 root root 4060 Nov 18 15:56 .. crw-rw----+ 1 root video 226, 0 Nov 18 15:55 card0 crw-rw-rw-. 1 root video 226, 64 Nov 18 15:55 controlD64 [ats@asus ~]$ rpm -qa |grep dracut dracut-008-0.10.gitb2415f4.fc15.noarch
My bad, it did work. I guess that I got the kernel before the dracut update, so I had to regenerate the initramfs. Now all is good. Thanks.
*** Bug 655309 has been marked as a duplicate of this bug. ***