Bug 768944

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.  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.