Closing the lid and opening it again fails to turn the backlight on. This fails equally with a kernel VT console and X. Matt Domsch mentioned that there is a hack you can add to make it work using programmed ACPI events. While this solution could be used, it is an incomplete solution. - How does our default distro know when to use it? - Will this work everywhere? The following cases wont. During Anaconda During Bootup where it wont have access to the ACPI event scripts Kernel panic, showing dump on the screen Perhaps the only complete solution is to fix the BIOS? NOTE: Close this bug only if LCD backlight behaves as expected, out-of-the-box, with default configurations of Fedora.
I have a similar (the same?) problem on a D820. The workaround was: enable in /etc/acpi/events/video.conf: event=video.* action=/usr/sbin/vbetool dpms on In rawhide this was suffficent to get it working here. In fc6 this still failed to bring the screen back. In addition there I had to add to my /etc/X11/xorg.conf: Section "ServerFlags" Option "NoPM" "true" EndSection So, this surely seems like a ACPI bug in the BIOS on these laptops. I agree that the above workarounds are just that, workarounds until the BIOS is fixed. Happy to test new bioses or provide more info.
Is this better in X with the intel driver (which we default to now)?
I just tried with the 20070411-i386-live usb image. No change. Closing the lid makes the screen blank, and then never come back. I tried to change the acpi video.conf, but acpid doesn't seem to be installed on the livecd. ;(
Somewhere between the new d620 bios and installing f7t4 fresh, I can no longer reproduce this problem. No config changes were made whatsoever.
On my d820, now upgraded to rawhide, I still see this. I can work around it by uncommenting the lines in /etc/acpi/events/video.conf: event=video.* action=/usr/sbin/vbetool dpms on It then works fine. Might be a change between the d820 and d620 bioses.
Kevin, if you want to fix this for resume you might want to checkout http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html and maybe add a --quirk-dpms-on flag.
In reply to comment #6: yeah, suspend/resume already works just fine. It already has the right quirks. ;) It's only closing the lid/reopening it (without suspending) that has this behavior.
Retest with latest rawhide with default settings?
Sorry for the delay. Just tested with the f8test2 live usb image... It seems to work correctly now out of the box and do the right thing. This can be closed RAWHIDE as far as I'm concerned.
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.
Closing per comment #9.