Hide Forgot
Created attachment 548579 [details] glxinfo output Description of problem: Gnome-session starts in fallback mode in F16 on a Dell E6400 laptop. The same computer (multi-boot) booted into F15 starts in Gnome3 native mode. This happens when using the same kernel (at the moment 3.2.0-rc6) compiled for both F16 and F15 from the same directory tree with the same .config file. Starting up with Mesa libraries, feel free to switch to other components if you feel that's a better idea. Version-Release number of selected component (if applicable): [root@duff ~]# rpm -qa | grep -i mesa | grep x86 | sort mesa-dri-drivers-7.11.2-1.fc16.x86_64 mesa-dri-filesystem-7.11.2-1.fc16.x86_64 mesa-libEGL-7.11.2-1.fc16.x86_64 mesa-libGL-7.11.2-1.fc16.x86_64 mesa-libGLU-7.11.2-1.fc16.x86_64 How reproducible: 100%. Steps to Reproduce: 1. start up in non-graphical mode 2. type 'startx' 3. observe a full Gnome3 session in F15, a fallback session in F16 Actual results: F16: Gnome fallback session starts Expected results: F16: Gnome3 native session starts Additional info: This issue is logged apparently under bug 768289 but perhaps with a bit less accuracy. Up to you if you want to merge this bug under 768289; for now I'm uploading evidence here. Another similar discussion where I initially reported my issue is also happening here: http://forums.fedoraforum.org/showthread.php?t=272917
Created attachment 548580 [details] Xorg.0.log from F16
I can confirm a similar problem with my HP DM1 4050 with Sandy Bridge Intel i3-2367M CPU. The system operates in gnome fallback mode for F16 and external monitor will not function. I can only get the system to boot in a working state with the nomodeset kernel parameter. Yet on the exact same computer F15 works perfect with good graphics response and external monitor works great! Please let me know if I can provide additional information to help with fixing this bug. Thanks.
(In reply to comment #2) > I can confirm a similar problem with my HP DM1 4050 with Sandy Bridge Intel > i3-2367M CPU. The system operates in gnome fallback mode for F16 and external > monitor will not function. I can only get the system to boot in a working > state with the nomodeset kernel parameter. Yet on the exact same computer F15 > works perfect with good graphics response and external monitor works great! > Please let me know if I can provide additional information to help with fixing > this bug. Thanks. I should add in both cases I made no changes to the kernel and applied all updates to F16.
(In reply to comment #2) > I can confirm a similar problem with my HP DM1 4050 with Sandy Bridge Intel > i3-2367M CPU. The system operates in gnome fallback mode for F16 and external > monitor will not function. I can only get the system to boot in a working > state with the nomodeset kernel parameter. Then your problem is different. 'nomodeset' disables KMS which all accelerated 3D requires. Your problem is that nomodeset is required. Alessandro's problem is that 3D isn't working even without nomodeset.
Reporter, check the permissions on /dev/dri/* (both with ls and with getfacl). I'm going to bet you simply don't have permissions on the device node for some reason, since your X log appears to be setting up DRI just fine.
Spot on... [root@duff ~]# ls -l /dev/dri/* crw-rw----+ 1 root video 226, 0 Jan 3 20:11 /dev/dri/card0 crw-------. 1 root video 226, 64 Jan 3 20:11 /dev/dri/controlD64 [root@duff ~]# getfacl /dev/dri/* getfacl: Removing leading '/' from absolute path names # file: dev/dri/card0 # owner: root # group: video user::rw- group::rw- mask::rw- other::--- # file: dev/dri/controlD64 # owner: root # group: video user::rw- group::--- other::--- I added my non-root user to the "video" group, and that was enough to start up Gnome3 in native mode. Yay :) I'm not closing the bug just yet as I'd like to know what the "right" fix for this should be; my custom kernel build is the same, .config-wise, in F15 and F16 - but where one works, the other fails; and my user does not belong to the "video" group in F15. In the meantime, thanks for your support !
As an additional note, while focusing on the video part I didn't realize I was missing audio as well for my non-root user, and sure enough adding said user in /etc/group to "audio" gave me back my F15 experience. I must be doing something wildly different than the mass of F16 users, if nobody complained so far. "Peculiar" things I do include: - having a multi-boot machine, sharing /boot (currently OEL4, OEL5, F15, F16) - my "upgrade" to F16 consisted in fresh-installing F16 on the former F14 root partition (re-formatting the partition during install), copying over /home and copying or adapting a few files in /etc, restorecon of said files - without touching F15 on alternate root partition; when F17 is released, I'll redo the same, installing F17 in the former F15 root - starting in runlevel 3 (no GDM) and then running startx - compiling custom kernel.org kernel on Fedora-current and using it on F-1 (single kernel binary for all Fedoras) ...none of which appear to me as impacting in any way an issue of needing users in "audio" and "video" groups to use Gnome3 acceleration or sound, especially given that F15 works fine without users belonging to such groups (moreover, the "Users and groups" app in F16 doesn't add newly created users to either "audio" or "video" by default).
I'm going to guess this should be addressed in startx's integration with whatever's replacing ConsoleKit this week.
My issue got resolved with a bios update. I don't know why I didn't think of that earlier. Now F16 works great with external monitor and accelerated video....
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
As per the above warning I received in email, it still appears even in F17 that if you boot up in the functional equivalent of old runlevel 3, log in to the console tty, fire up 'startx' from a bash shell - then you will NOT have working audio/video within the GNOME session - UNLESS your user belongs to the audio/video groups. Bug ? Yes, belonging to those groups wasn't required for appropriate functionality of audio/video up until F15. Going to be fixed ? It appears not, so I'll just stick to the workaround of manually adding my users to groups audio/video by default.