Bug 423931 - M4300 backlight doesn't go off when lid is closed
Summary: M4300 backlight doesn't go off when lid is closed
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gnome-power-manager   
(Show other bugs)
Version: 5.1
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Richard Hughes
QA Contact: desktop-bugs@redhat.com
: 423991 (view as bug list)
Depends On:
Blocks: 391501
TreeView+ depends on / blocked
Reported: 2007-12-13 19:47 UTC by Larry Troan
Modified: 2018-10-20 01:20 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 20:50:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
requested xorg.conf file - from stock install of RHEL5.2 (799 bytes, application/octet-stream)
2008-07-14 14:52 UTC, Chris Tatman
no flags Details
tail -f on user .xsession-errors while closing and opening the lid (813 bytes, application/octet-stream)
2008-07-14 14:54 UTC, Chris Tatman
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0082 normal SHIPPED_LIVE gnome-power-manager bug fix update 2009-01-20 16:04:20 UTC

Description Larry Troan 2007-12-13 19:47:16 UTC
Description of problem:
Running RHEL5.1 x86_64, the Dell Precision Mobile M4300 backlight goes out and
then comes back on when the lid is closed. It needs to stay out to pass

How reproducible:
Power up the M4300, close the lid and observe the light by peering through the
slit between the keyboard and the top.

Actual results:
Back light goes out and then comes back on when lid is closed.

Expected results:
Back light should remain off to conserve battery power until lid is reopened.

Additional info:
Verify BIOS is latest before debugging (believe 05).

Comment 1 John Feeney 2008-01-26 00:13:24 UTC
Just an update on what I know:

Yes, the most recent bios (A05) is loaded.

I have used the nVidia binary driver (vers 169.09) as well as the Vesa 
xorg driver but neither have an effect on the backlight when the lid is 
closed as far as I can tell.

I have noted that the button acpi driver is notified of the lid position
and correctly updates the /proc/acpi/button/lid/LID/state contents
(e.g. "open" when open and "closed" when closed). gnome-power-manager
says "DPMS blanking screen because lid has been closed on ac power" when
closed and "Turning LCD panel on..." when re-opened.

I noticed that the backlight flashes when the lid is just about closed. 
Could this be the backlight is correctly turned off but then something
incorrectly turns it back on, hence the flash? 

Looked for bios options but found nothing. Played with Preferences' Power 
Management options (suspend on lid close works) but "blank screen" still 

Comment 2 John Feeney 2008-01-28 20:44:13 UTC
Dell has found that with the addition of "xset dpms on/off" directive, the 
binary nVidia driver will turn off the backlight when the lid is closed. Thus, 
it would appear as though the issue is in the nv and vesa xorg drivers.  As a
result, I am re-assigning this bugzilla.

Comment 3 RHEL Product and Program Management 2008-01-29 22:55:39 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 4 Rezwanul Kabir 2008-01-30 04:02:59 UTC
I don't see any root cause of this issue being described. Need more info on 
exactly what is broke and needs to be fixed before this is pushed out to next 
release. This issue blocked Dell's certification of RHEL5.1, so it needs more 

Comment 6 Richard Hughes 2008-04-17 12:46:20 UTC
Does the backlight come on by itself? If you disconnect all additional keyboards
and mice from the laptop, and then close the lid - does the backlight stay off?

Could you also do:

lshal -m
<shut lid>
<wait 5 seconds>
<open lid>
<wait 5 seconds>

and attach the information here. Many thanks.

Comment 7 Chris Tatman 2008-04-17 22:12:56 UTC
Hi Richard,

The backlight never turns off.  That's the problem.  The screen blanks per the
setting in gnome-power-preferences, but the backlight stays on.  There are no
additional keyboards, mice, or other peripherals attached to the laptop.

# lshal -m

Start monitoring devicelist:
acpi_LID property button.state.value = true
acpi_LID condition ButtonPressed = lid
acpi_LID property button.state.value = false
acpi_LID condition ButtonPressed = lid

Comment 8 Richard Hughes 2008-04-18 12:22:24 UTC
Chris, does the backlight turn off when you do "xset dpms force off"


Comment 9 Chris Tatman 2008-04-18 13:29:29 UTC
Hi Richard,

Yes.  The backlight does turn off with that command.  Quick question here.  Is
it possible to put this command into the /etc/acpi/events/ directory?  Maybe a
lidclose event of some kind?


Comment 11 Chris Tatman 2008-05-13 19:21:23 UTC

Testing on RHEL5.2 Snapshot7 shows that this is still an issue.  However,
the 'xset dpms force off' command does now work with the open source
nv driver.  And if I ssh into the box while closing the lid, I can see the
following message in syslogs when shutting the lid on the laptop:

May  6 15:46:26 dhcp243-6 gnome-power-manager: (ctatman) DPMS blanking
screen because the lid has been closed on ac power

Can a script be provided that calls on 'xset dpms force off' when the lid is
shut to fix this issue?  I used to put my scripts in the /etc/acpi
directory, but this does not appear to be working any more.  Does pm-utils
look elsewhere?


Comment 12 John Feeney 2008-05-22 18:44:51 UTC
Who has the ball on this? It looks like Chris responded but it is still
NEEDINFO for Larry but I don't see what is being asked of Larry.

Comment 13 Dave Maley 2008-06-05 19:39:39 UTC
re-assigning to g-p-m

Comment 14 RHEL Product and Program Management 2008-06-05 19:55:03 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 21 Richard Hughes 2008-07-14 09:12:06 UTC
I really think g-p-m is doing the right thing here. You can see in
that the rpm's are being built with DPMS support, and #c1 seems to verify that
gnome-power-manager is talking to X asking to turn the panel off.

It's very hard to debug this without any hardware to poke at.
Actions I have for people with hardware:

1. does "xset dpms off" blank the same as "xset dpms force off"?
2. can you attach the complete X11/xorg.conf
3. are there any errors in .xsession-errors when you shut and re-open the lid?
4. are you using the nv, nvidia or vesa driver?
5. when the lid is shut (you emulate with a paperclip if it's a switch) does the
panel flicker before going black?
6. Are any keys being pressed or mice being moved when the lid is shut?

I've a funny feeling that Dell hardware does not kill the screen in hardware on
lid close, XOrg is turning it off, and then something else is turning it on
again. Maybe the lid close event wakes up the panel after g-p-m has asked it to
sleep, and a few ms delay in g-p-m might do the trick.

We don't want to add the events.d "fix" as this is just a hack around the real
problem and might break existing setups.

Comment 22 Chris Tatman 2008-07-14 14:51:22 UTC
Hi Richard,

1. does "xset dpms off" blank the same as "xset dpms force off"?

xset dpms off - returns an error 
xset: unknown option off

xset dpms force off - blanks the screen

2. can you attach the complete X11/xorg.conf

3. are there any errors in .xsession-errors when you shut and re-open the lid?
No errors.  Attaching 'tail -f' capture file.

4. are you using the nv, nvidia or vesa driver?
Using the nv driver.  However, the vesa driver appears to be doing the same
thing as well.

5. when the lid is shut (you emulate with a paperclip if it's a switch) does the
panel flicker before going black?

There is no switch that I can see for doing this.  However, I can peer
underneath the lid while it is closed (there's a gap), and there does not seem
to be any flickering.

6. Are any keys being pressed or mice being moved when the lid is shut?

Comment 23 Chris Tatman 2008-07-14 14:52:28 UTC
Created attachment 311716 [details]
requested xorg.conf file - from stock install of RHEL5.2

Comment 24 Chris Tatman 2008-07-14 14:54:06 UTC
Created attachment 311717 [details]
tail -f on user .xsession-errors while closing and opening the lid

Comment 26 Richard Hughes 2008-08-14 11:01:48 UTC
Right, I've now got my own Dell M4300 to play with. I can reproduce the bug, but it's very confusing.

sudo killall hald
killall gnome-screensaver
killall gnome-power-manager
acpi_listen &
xset dpms force off

-panel goes black-

{shut lid}

# button/lid LID 00000080 00000011

about 4mm from actually stutting the lid, the panel backlight is turned on

{open lid}

# button/lid LID 00000080 00000012

So we can rule out bugs in hal, gnome-power-manager or gnome-screensaver.

So, I wanted to see if we could re-turn the panel off:

sleep 5 && xset dpms force off &
xset dpms force off

-panel goes black-
{shut lid}
-panel comes back on-
{wait 5 seconds}
-panel goes black-

So something is turning the panel back on when we shut the lid.

Sanity check:

/sbin/init 1

{shut lid}
# button/lid LID 00000080 0000001b
{open lid}
# button/lid LID 00000080 0000001c

So we have different ACPI event codes if we are in X or text mode. I'll turn my attention to X and the kernel to try and work out what's awaking the display.

Comment 28 Richard Hughes 2008-08-14 11:59:17 UTC
XOrg (hw/xfree86/os-support/linux/lnx_acpi.c) seem to only parse the "VIDEO" events, not the LID events. We're thinking this is a generated keypress that is waking up X.

Comment 29 Richard Hughes 2008-08-14 12:05:32 UTC
Is this NVIDIA graphics specific? Can anyone reproduce with ATI or Intel graphics?

Comment 30 Richard Hughes 2008-08-14 13:11:35 UTC
If I do:

service acpid stop
xset dpms force off

then shut the lid, it stays blank. Unloading the button kernel module does the trick too. I'm sure none of the script in /etc/acpi/events are getting run, so this must be X (userspace) rather than anything in BIOS / kernel.

Comment 31 Richard Hughes 2008-08-14 13:53:34 UTC
Okay, I've worked around this the same way as in upstream. Can you please try the rpms here: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=1432175

If they work (or improve the situation), then these are good to go.

Comment 32 Issue Tracker 2008-08-14 14:24:01 UTC
Hi All,

I just tested the rpm out, and it seems to have fixed the issue.  I now
see the backlight turning off when I close the lid.

note: Had to reboot the laptop after installing the rpm before it worked. 
Maybe I just needed to restart X?

Anyway, thanks Richard!


This event sent from IssueTracker by ctatman 
 issue 163882

Comment 33 Marizol Martinez 2008-08-14 19:45:43 UTC
Rez -- Here are the rpms so you can test them as well:


Let us know how it goes!

Comment 34 Richard Hughes 2008-08-22 16:56:41 UTC
Patch committed and building, http://brewweb.devel.redhat.com/brew/taskinfo?taskID=1435308

Comment 37 Matthias Clasen 2008-09-16 13:34:31 UTC
*** Bug 423991 has been marked as a duplicate of this bug. ***

Comment 39 Zack Cerza 2008-10-30 19:37:18 UTC
VERIFIED in gnome-power-manager-2.16.0-10.el5

Comment 41 errata-xmlrpc 2009-01-20 20:50:54 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.