Red Hat Bugzilla – Bug 230670
D620: LCD backlight doesn't come back when you open lid
Last modified: 2014-03-16 23:05:54 EDT
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
- How does our default distro know when to use it?
- Will this work everywhere? The following cases wont.
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:
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:
Option "NoPM" "true"
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
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:
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
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:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Closing per comment #9.