closed Laptop Lid to reliably keep Backlight off

I can't quite replicate this on my ThinkPad as the hardware takes care of forcing the backlight off when the lid is shut (...to stop the keyboard melting!).

Can you paste the output from:

  $ lshal -m

when you do this.

Richard: how would g-p-m detect that there has been mouse-movement, or is this actually the screensaver or hardware doing this?

I closed the lid, waited for some seconds (to work around bug 30802), moved the mouse (watching the backlight switch back on) and opened the lid (unlocked the session), so I could read the following output:

$ 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

The output is the same when I do not move the mouse inbetween closing and opening the lid.

Tested on Flight 6 dist-upgraded today.

I don't see bugs 30802 and 41994 are duplicates.

Bug 30802 is about that the backlight does not switch off in certain situations where it should.
Bug 41994 is about taht the backlight switches back on in some situations where it should not.

This issue is still present on Flight 7.

This issue is still present on the Release Candidate. I have removed the duplicate status, because I cannot see a reason for this, and no one explained.

This bug still exists on Feisty on my MacBook.

This bug also exists on my MacBook using gnome-power-manager 2.14.3

I confirm that the bug still exists on my Macbook using feisty

Exists on HP Compaq nc6320 with Gutsy. Workaround is to set GPM to do "nothing" when the lid is closed. Either the hardware or some other driver sucessfuly takes care of blanking the screen and keeps it off even with mouse movement.

Replicable on Macbook first generation with Gutsy, but here setting GPM to do "nothing" simply do nothing, as in "the light remains on". Either lshal -m doesn't show anything different when moving the mouse.

This issue is still present on Gutsy Tribe 4 (on my Dell Latitude X1).

I have the same problem but here is my output of "$ lshal -m"

@monkey:/etc/acpi$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
00:51:06.571: computer_logicaldev_input_0 property button.state.value = true ##LID GETS CLOSED HERE##
00:51:06.576: computer_logicaldev_input_0 condition ButtonPressed = lid
00:51:06.578: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode ##BACKLIGHT TURNS ON HERE?##
00:51:06.585: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
00:51:18.808: acpi_BAT0 property battery.voltage.current = 12531 (0x30f3)
00:51:26.973: computer_logicaldev_input_0 property button.state.value = false ##LID OPENED HERE##
00:51:26.976: computer_logicaldev_input_0 condition ButtonPressed = lid
00:51:26.995: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
00:51:27.032: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
00:53:18.809: acpi_BAT0 property battery.voltage.current = 12532 (0x30f4)
00:53:48.812: acpi_BAT0 property battery.voltage.current = 12531 (0x30f3)

I'm not sure if it'll have any ill effects, but my problem went away by commenting out all lines in the
/etc/acpi/events/videobtn file and then rstarting acpid. I assume this causes the acpid to ignore the
event that is triggering the backlight to come back on when the lid is still closed.

The backlight now stays off unless the lid is opened or an actual button is pressed.

I had the same problem. I closed the lid of my laptop, then the backlight went out. But a fraction of a second later, it wen back on. The fix of mackkie worked for me too.

This bug didn't happen for me in Feisty Fawn, but only in Gutsy Gibbon.

I use an Dell Inspiron 9400.

Maybe this could help?

Start monitoring devicelist:
-------------------------------------------------
07:41:08.020: computer_logicaldev_input_0 property button.state.value = true
07:41:08.025: computer_logicaldev_input_0 condition ButtonPressed = lid
07:41:08.031: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
07:41:08.043: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
07:41:12.137: computer_logicaldev_input_0 property button.state.value = false
07:41:12.141: computer_logicaldev_input_0 condition ButtonPressed = lid
07:41:12.160: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
07:41:12.178: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode

I have the same problem on a Dell Inspiron 9400.

After a few tests I've seen the following:
- "Normally" the backlight remains on, even with the lid closed.
- If I kill gnome-power-manager the backlight goes off on lid close.
- If I kill acpid (gpm is on) the light goes off as well.
- If I apply mackkie's fix the light goes off after lid close as well.

I don't really know why touching videobtn has an impact on something related to the lid button, but it does.
Another interesting point is that the CheckPolicy check in lid.sh would prevent this script from running if gpm is running,
so it doesn't seem to be doing anything during these tests.

What I've noticed is that I always get a couple of video button events right after the pid-down event.

I don't know what the relationship between gpm and acpid is (as I believe the gpm works directly with HAL).

Hope this helps somehow.

This issue is still present on Hardy Alpha 1.

I've seen the backlight come on right after going off, without moving the mouse or something.

Also, when I re-open the lid, metacity is being unloaded and re-loaded - I've not tried compiz yet.

With 7.10 and Dell Inspiron 6400(1505) the light goes off as soon as lid is closed, but after half second turns on whenever the mouse is moved or not.
Killing gnome-power-manager results an even stranger behaviour: the lights go off, than turns on for a brief period than turned off again. But moving a mouse cases the light to be turned on again.
Mackkie's fix does not do any apparent difference.
Stopping acpid results the light to go off normally as soon as lid is closed, but moving a mouse turns it on again.

lshal results with everything configured as default:
zigmar@thin-avalon-lnx:~$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
23:03:49.222: computer_logicaldev_input_0 property button.state.value = true
23:03:49.227: computer_logicaldev_input_0 condition ButtonPressed = lid
23:03:49.245: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
23:03:49.296: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
23:03:58.785: computer_logicaldev_input_0 property button.state.value = false
23:03:58.792: computer_logicaldev_input_0 condition ButtonPressed = lid
23:03:58.804: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
23:03:58.827: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode

and with acpid stopped:
zigmar@thin-avalon-lnx:~$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
23:05:35.008: computer_logicaldev_input_0 property button.state.value = true
23:05:35.012: computer_logicaldev_input_0 condition ButtonPressed = lid
23:05:41.704: computer_logicaldev_input_0 property button.state.value = false
23:05:41.708: computer_logicaldev_input_0 condition ButtonPressed = lid

This issue is still present in Hardy Alpha 3 on a Dell Inspiron 1520 (Intel X3100 graphics card).

I want my laptop to do some big downloads over night. I set it to work, close the lid, and go to bed. Seconds later, the backlight comes back on. It is very difficult to go to sleep in a room with thin crack of eerie light emanating from a closed laptop. More to the point, it can't be doing the laptop much good, either.

This issue remains even if the screensaver is set to blank screen - the pixels go dark but the backlight comes back on!

I have this issue with an Inspiron 6000 and Ubuntu 7.10
My video card is an Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

Here's my workaround script which fixes this problem provided you don't have more than one X session (ie. you never use "switch users"). This is a quick and dirty hack which should be replaced by something much cleverer ASAP. Become root and save it as: /etc/acpi/local/lid.sh.pre

Tested on Ubuntu Hardy Alpha 4 on a Dell Inspiron 1520 only. May or may not work with Gutsy and other prior versions, comment here and let people know. Use at your own risk.

#!/bin/sh
# /etc/acpi/local/lid.sh.pre for Ubuntu Hardy Alpha 4 and possibly others
# v0.1 Andrew Oakley www.aoakley.com 2008-02-02 Public Domain
# Workaround to ensure LCD display remains off on laptops when lid is closed
# even if there is external keyboard/mouse movement (eg. docking station).
# This file should be owned by root and set: chmod 755
# This is a quick and dirty workaround which assumes only ONE X session!
# Also has bug whereby if you close lid, then hibernate/suspend, then resume,
# LCD won't come back on until you re-close and re-open the lid.
export XAUTHORITY=`ls -1 /home/*/.Xauthority`
export DISPLAY=:0
grep -q closed /proc/acpi/button/lid/*/state
if [ $? = 0 ]
then
  xrandr --output LVDS --off
else
  xrandr --output LVDS --auto
fi

@andrew

Thanks for the fix. It works as advertised. :)

This appears to have been fixed in March:

http://svn.gnome.org/viewvc/gnome-power-manager/trunk/src/gpm-backlight.c?view=diff&r1=1982&r2=1983

You should be seeing events in the log files to signify the different buttons being pressed. Could you please run your GPM in verbose mode and ensure that it's not getting a LID_OPEN button event?

Thanks.

https://wiki.ubuntu.com/DebuggingGNOMEPowerManager#head-7d2eb767e44a7231fae6964dcf12bc27fe507c9d

You're right, it doesn't seem to happen anymore.

It still does not work on my machine (Dell X1). Here is the logfile with my comments inbetween:

# Closing the lid...

[hal_device_condition_cb] gpm-button.c:393 (11:09:54): condition=ButtonPressed, details=switch-videomode
[emit_button_pressed] gpm-button.c:337 (11:09:54): emitting button-pressed : switch-videomode
[button_pressed_cb] gpm-manager.c:999 (11:09:54): Button press event type=switch-videomode
[button_pressed_cb] gpm-srv-screensaver.c:167 (11:09:54): Button press event type=switch-videomode
[button_pressed_cb] gpm-backlight.c:515 (11:09:54): Button press event type=switch-videomode
[button_pressed_cb] gpm-info.c:698 (11:09:54): Button press event type=switch-videomode
[hal_device_property_modified_cb] gpm-button.c:363 (11:09:54): key=button.state.value, added=0, removed=0, finally=1
[hal_device_property_modified_cb] gpm-button.c:372 (11:09:54): state of a button has changed : /org/freedesktop/Hal/devices/computer_logicaldev_input_2, button.state.value
[emit_button_pressed] gpm-button.c:337 (11:09:55): emitting button-pressed : lid-down
[button_pressed_cb] gpm-manager.c:999 (11:09:55): Button press event type=lid-down
[lid_button_pressed] gpm-manager.c:952 (11:09:55): Performing AC policy
[gpm_inhibit_has_inhibit] gpm-inhibit.c:336 (11:09:55): Valid as no inhibitors
[manager_policy_do] gpm-manager.c:470 (11:09:55): policy: /apps/gnome-power-manager/buttons/lid_ac
[gpm_control_get_lock_policy] gpm-control.c:389 (11:09:55): Using custom locking settings (0)
[button_pressed_cb] gpm-srv-screensaver.c:167 (11:09:56): Button press event type=lid-down
[gpm_screensaver_add_throttle] gpm-screensaver.c:318 (11:09:56): adding throttle reason: 'Laptop lid is closed': id 96633217
[button_pressed_cb] gpm-backlight.c:515 (11:09:56): Button press event type=lid-down
[button_pressed_cb] gpm-info.c:698 (11:09:56): Button press event type=lid-down
[gpm_info_event_log] gpm-info.c:594 (11:09:56): Adding 8 to the event log
[button_pressed_cb] gpm-info.c:704 (11:09:56): lid button CLOSED
[hal_device_condition_cb] gpm-button.c:393 (11:09:56): condition=ButtonPressed, details=lid
[emit_button_pressed] gpm-button.c:314 (11:09:56): ignoring duplicate lid event
[hal_device_condition_cb] gpm-button.c:393 (11:09:56): condition=ButtonPressed, details=switch-videomode
[emit_button_pressed] gpm-button.c:337 (11:09:56): emitting button-pressed : switch-videomode
[button_pressed_cb] gpm-manager.c:999 (11:09:56): Button press event type=switch-videomode
[button_pressed_cb] gpm-srv-screensaver.c:167 (11:09:56): Button press event type=switch-videomode
[button_pressed_cb] gpm-backlight.c:515 (11:09:56): Button press event type=switch-videomode
[button_pressed_cb] gpm-info.c:698 (11:09:56): Button press event type=switch-videomode
[dpms_mode_changed_cb] gpm-srv-screensaver.c:196 (11:09:56): DPMS mode changed: 3
[gpm_screensaver_add_throttle] gpm-screensaver.c:318 (11:09:56): adding throttle reason: 'Display DPMS activated': id 491953026
[mode_changed_cb] gpm-backlight.c:673 (11:09:56): emitting mode-changed : off
[dpms_mode_changed_cb] gpm-profile.c:654 (11:09:56): DPMS mode changed: 3
[dpms_mode_changed_cb] gpm-info.c:751 (11:09:56): DP...

This is still a problem with Hardy Beta and all updates to date 2008-04-09 on a Dell Inspiron 1520 with Intel X3100/i965 graphics. Re-marking as confirmed.

The problem is NOT that the LCD doesn't switch off when the lid closes. The problem is that the LCD turns back on again when the lid REMAINS closed but there is external keyboard or mouse activity (eg. USB keyboard, USB mouse).

My workaround continues to correct this behaviour, but only if you only have one X session. My workaround is not good enough.

Attaching gpm.debug.log.txt . This shows:

* Lid is closed

* LCD turns off (correct behaviour)

* USB mouse is moved

* LCD turns on (lid remains closed; LCD turns on with lid closed; WRONG BEHAVIOUR)

* Lid is opened

* LCD remains on

* Lid is closed again

* LCD turns off (correct behaviour)

* USB mouse is moved

* LCD turns on again (lid remains closed; LCD turns on with lid closed; WRONG BEHAVIOUR)

* Lid is opened

* LCD remains on

On a Dell Inspiron 1520 with Intel X3100/i965 graphics, Hardy with all updates to date 2008-04-09.

Unfortunately this is not an easy fix. Currently GPM has no distinction
between the laptop panel and an external display. So if someone had
their external display go to sleep, we wouldn't know which one to wake
and which one to not.

While I agree that it is good to fix, I don't think it is reasonable to
add during feature freeze as much code (and dependencies) would have to
change.

I would recommend filing a bug upstream (bugzilla.gnome.org) as they're
currently planning for the next version of GNOME. Please link the bug
here.

Fair enough. The next best situation for Hardy, would be to perfect my workaround script /etc/acpi/local/lid.sh.pre ( https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/41994/comments/21 )

Currently the script detects the XAUTHORITY and DISPLAY environment variables in this manner:

export XAUTHORITY=`ls -1 /home/*/.Xauthority`
export DISPLAY=:0

This is unreliable as I understand things (which may be wrong), since with multiple concurrent logged-on desktop users ("switch users"), there may be more than one .Xauthority file and more than one display.

How, in a shell script or similar, can I detect the currently active console .Xauthority and currently active console display, even if there are multiple concurrent desktop users logged in?

On Thu, 2008-04-10 at 08:09 +0000, Andrew Oakley wrote:
> Fair enough. The next best situation for Hardy, would be to perfect my
> workaround script /etc/acpi/local/lid.sh.pre (
> https://bugs.launchpad.net/ubuntu/+source/gnome-power-
> manager/+bug/41994/comments/21 )
>
> Currently the script detects the XAUTHORITY and DISPLAY environment
> variables in this manner:
>
> export XAUTHORITY=`ls -1 /home/*/.Xauthority`
> export DISPLAY=:0
>
> This is unreliable as I understand things (which may be wrong), since
> with multiple concurrent logged-on desktop users ("switch users"), there
> may be more than one .Xauthority file and more than one display.
>
> How, in a shell script or similar, can I detect the currently active
> console .Xauthority and currently active console display, even if there
> are multiple concurrent desktop users logged in?

You can use ConsoleKit:

http://people.freedesktop.org/~mccann/doc/ConsoleKit/ConsoleKit.html

using the dbus-send command line tools to query the current session and
figure out it's properties. This should work with fast-user switching
and other technologies.

Just found out the same thing happens on Intrepid Alpha 5, up to date sept 08, 2008, HP Compaq nx6125.

Same output as second post.

Don't know if this happened before.

I've been having the same trouble with Hardy. I have a HP Compaq nc6000 and use the fglrx drivers.

My solution is two-fold:
1) change the gnome-power-manager settings so that "nothing" is done on a lid closure. This fixes the issue with mouse movements turning on the display (or anything, really - maybe not useful for a laptop connected to external monitor).
2) At this point, the backlight is shut off, but there is still an image displayed on the screen (as can be seen in bright light). The "radeontool" must be used to turn off the screen. I modified the above lid.sh.pre script (after giving executable permission! That cause me lots of frustration!) by copying the two lines in lid.sh that turn on and off the light using radeontool to the respective places in lid.sh.pre

This is a quick hack (as most of this thread is about, but it make me happy!)

I should mention that step 1 only works with the fglrx drivers, and perhaps VESA, because the lid switch is controlled through the bios naturally (I think). I had all sorts of trouble getting the lid switch to work at all (cpu overload.. another bug) using the "ati" / "radeon" drivers.

A way to check is to kill the gnome-power-manager and try the lid switch. Mine worked perfectly if it was killed, so I did everything to disable its effects when it is running (hence setting it to "nothing")

I have a pretty much similar problem. Though the laptop screen just turns straight back on again without even waiting for me to hit the keyboard.

I have a Dell D520 on a docking station. I turn it on with the lid closed and use the external keyboard and screen. It was with some dismay I noticed that the screen has been on for hours on end, explains why the laptop screen is a bit dull now, it's aged.

So I turned it on with a bit of cardboard holding the lid button down. It boots with the laptop screen off, the external on. Right up until X (gdm login) gets going the laptop screen is off ... but then, on it goes.

I tried the script above in /etc/acpi/local ... I did not have a local dir (running Ubuntu 8.04 and keeping it up to date) so I created one. No joy. No idea why.

In the meantime I have lifted the lid (so I can see - no longer "trust" ubuntu on this) inserted cardboard on the button and manually run the xrandr --ouput LVDS --off in a shell. This works.

this is the lshal -m output at the moment

---------
having manually (xrandr) fixed the prob, external:on laplcd:off

remove cardboard from lid switch (open the lid)

15:11:41.626: computer_logicaldev_input condition ButtonPressed = switch-videomode
15:11:41.629: computer_logicaldev_input_3 property button.state.value = false
15:11:41.632: computer_logicaldev_input_3 condition ButtonPressed = lid
15:11:41.787: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode

both screens on ... fine

replace cardboard (close the lid)

15:11:53.464: computer_logicaldev_input condition ButtonPressed = switch-videomode
15:11:53.475: computer_logicaldev_input_3 property button.state.value = true
15:11:53.476: computer_logicaldev_input_3 condition ButtonPressed = lid
15:11:53.632: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode

both screens on ... bother

xrandr --output LVDS --off

laplcd:off ... good

To add to the above, something else has changed, I now intermittently see a screen flicker. It's like some application wants to change my screen modes, starts to and then is immediately undone. lshal -m shows nothing when this is happens. Not sure where to look.

I am wondering if I need to just manually hack the xorg.conf file and somehow take gnome's handling of this out of the loop. So I am going to start here at https://help.ubuntu.com/community/XORGHardy

Hmmm, the flicker was a separate issue, must have been present before but never as noticeable. It needed an Option "FramebufferCompression" "false" in the Device section of xorg.conf to fix (work around) a problem apparently present with the 945GM chipset I have.

I can report the same problem with Intrepid on a Dell Inspiron 640m (E1405).
mackkie's fix works.
and here's the lshal output
$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
08:37:53.780: computer_logicaldev_input_2 property button.state.value = true
08:37:53.789: computer_logicaldev_input_2 condition ButtonPressed = lid
08:37:57.764: computer_logicaldev_input_2 property button.state.value = false
08:37:57.768: computer_logicaldev_input_2 condition ButtonPressed = lid

Hey i had the same probleme when i closed my laptop lid and moved the mouse the screen came back so i used the code in Andrew Oakley post and workt here is my lid.sh

and the code if your not registered:
#!/bin/bash
# TODO: Change the above to /bin/sh

test -f /usr/share/acpi-support/state-funcs || exit 0

. /usr/share/acpi-support/power-funcs
. /usr/share/acpi-support/policy-funcs
. /etc/default/acpi-support

export XAUTHORITY=`ls -1 /home/*/.Xauthority`
export DISPLAY=:0
grep -q closed /proc/acpi/button/lid/*/state
if [ $? = 0 ]
then

  xrandr --output LVDS --off
else
 xrandr --output LVDS --auto
     if [ $? = 1 ]
  then
  xrandr --output LVDS --on
fi
fi
i hope this will help!

The xrandr method mentioned above isn't working for me .. so a little bit of a brute force method is a custom daemon to turn off the screen if the laptop lid is closed.. compile with "gcc -o lidcheck lidcheck.c". I wanted it in C to reduce the memory footprint, but of course a simple shell script does the job just as well. It simple checks if the lid is closed, and if it is, it calls "xset dpms force off" .. this will probably cause adverse effects if you're using an external monitor.

http://rmt.pastebin.com/f41781d13

This bug is still present on Karmic.

I see it on my Dell Vostro 1500 with Karmic. (VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) )

Closing the lid results the backlight momentarily going out, then comes back on. From dmesg during a close:

[144302.896264] integrated sync not supported
[144302.940045] [drm] TV-14: set mode NTSC 480i 0
[144303.081299] [drm] TV-14: set mode NTSC 480i 0
[144304.213641] integrated sync not supported
[144304.257460] [drm] TV-14: set mode NTSC 480i 0
[144304.398855] [drm] TV-14: set mode NTSC 480i 0
[144307.116858] integrated sync not supported
[144307.158505] [drm] TV-14: set mode NTSC 480i 0
[144307.311088] [drm] TV-14: set mode NTSC 480i 0
[144307.806230] integrated sync not supported
[144307.848233] [drm] TV-14: set mode NTSC 480i 0
[144307.990254] [drm] TV-14: set mode NTSC 480i 0

Closing the lid for 10 seconds:
lshal -m

Start monitoring devicelist:
-------------------------------------------------
00:29:36.577: computer_logicaldev_input condition ButtonPressed = switch-videomode
00:29:36.592: computer_logicaldev_input_5 property button.state.value = true
00:29:36.602: computer_logicaldev_input_5 condition ButtonPressed = lid
00:29:37.607: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode
00:29:48.490: computer_logicaldev_input condition ButtonPressed = switch-videomode
00:29:48.495: computer_logicaldev_input_5 property button.state.value = false
00:29:48.496: computer_logicaldev_input_5 condition ButtonPressed = lid
00:29:49.147: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = switch-videomode

I'm also having the problem. Dell inspiron 1520, nVidia 8400m graphics.

lshal -m

Start monitoring devicelist:
-------------------------------------------------
21:13:27.339: computer_logicaldev_input_4 property button.state.value = true
21:13:27.344: computer_logicaldev_input_4 condition ButtonPressed = lid
21:13:34.638: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = play-pause
21:13:37.477: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = play-pause
21:13:38.604: computer_logicaldev_input_4 property button.state.value = false
21:13:38.612: computer_logicaldev_input_4 condition ButtonPressed = lid

The screen stays off as long as i don't press anything, but it comes back on when i press the play pause button, but obviously the system detects the lid being opened much later.

If I run "xset dpms force off", the screen will turn off but come back on if i press anything.

I am still having this issue in Karmic. Was there ever a fix? I'm on a Dell Latitude E6400, Intel Video.

The bug is still present on Lucid.

My Dell M4400 (Lucid x64) is also affected with this bug. When I close my notebook and move the mouse, the displaylight goes on.
This is really annoying. Any solutions yet?

I found a workaround in german from 2008 on this page: http://soltano.blogspot.com/2008/03/hp-compaq-6720s-der-tragdie-zweiter.html He used the vbetool dpms off command. I did not try it. Maybe someone finds it helpful.

I tried Mackkies workaround (commenting out all lines in the /etc/acpi/events/videobtn file). It did not work for me.

This bug causes my laptop to get really hot, especially in the summer, because the screen is acting as a radiator cooking my laptop. The xrandr workaround isn't working for me because I'm using the proprietary nvidia drivers. Maybe there's a way to disable any attached USB mouse or keyboard when the lid closes, which will prevent the screen from being woken up? that would work I think.

I can confirm this using both Ubuntu Maverick and Mint Julia amd64 on a Dell Studio 1555.
A little while after closing the lid, backlight switches on, apparently due to detected movement on trackpad because it is much less frequent when disconnecting USB mouse(but still happens).

I found what may lead to a solution: using vbetool instead of xset seems to ignore input.
instead of running
xset dpms force off,
using
sudo vbetool dpms off
will turn off the display and not turn on unless I close the lid(invoking the default screen blanker) and then move the mouse, press a button or something else.

I don't have time right now to make a replacement lid.sh, but I'll post one asap(if I can somehow call sudo without a password prompt... oh yeah, i can mod whatever sudo file to allow vbetool), and later maybe look at the source code in order to get a real fix.

Working on an Inspiron 1520 with an nVidia 8600m GT, proprietary drivers

I can't believe this is another 5+ year old bug that is still unresolved. I am experiencing this issue on Ubuntu/Xubuntu 11.04. The problem is that somehow dpms calls are being made to turn the backlight back on when a mouse event occurs, even though the lid is still shut.

I ran into some difficulty because the Ubuntu acpi-support scripts don't run if they detect a desktop (gnome/kde/xfce/etc) power-manager app running. It's a pain to have to kill those, because I lose all GUI-based power management (battery indicator, etc.) on my laptop. However, I got so fed up with this issue that I felt it was worth it to block the power-manager app so that acpid could run the show.

In the end, the best solution I could find was to run lid.sh on a 1-minute recurring cron job. This forces the backlight off when the lid is closed and on when it's open. Not a very elegant solution, but at least I won't have to worry about burning out my laptop's monitor any more.

Also vbetool did not work for me. Specifically, it was able to turn off the backlight, but was not able to turn it back on. After using vbetool to turn off the backlight, I had to switch to a text console and back to get the backlight to come back on!

I have noticed this problem also, since I got my laptop back on Ubuntu 10.10, and it is still a problem on 11.10. The only difference is I am not giving it any input, it wakes up on it's own.

I remember back in 10.10, with a friend, we tried to debug the problem. We first looked at some logs, whenever the screen turned back on, there was a message something like, "X no longer idle". The only reason my friend could think of, for the X server to not be idle is that it received some input. So, we ran the program which shows any input received (might have been xev?), and tested again, but this showed that the system was not receiving any input. So, we were unable to work out why X is would stop being idle (and turn the screen back on).

Status changed to 'Confirmed' because the bug affects multiple users.

I'm pretty sure it's xset's dpms functionality that is behind this issue.

Status changed to 'Confirmed' because the bug affects multiple users.

Using 11.10 I did a kernel patch but it still goes black and you need to close and reopen led to get screen back bright. Very annoying at our library as we have 10 laptops running Ubuntu.

I have found a gnome-shell extension which adds a menu item to blank the screen.

This seems to work perfectly, perhaps the code used in there can be used when the laptop lid is closed? I don't see why a quick extension can do this better than the main system.

https://extensions.gnome.org/extension/242/blank-screen/

Fixing this one seems like it will be pretty complex, disqualifying it as a papercut.

I can blank the screen using the command "xset dpms force off", and it doesn't turn back on. Can't it just run that when the lid is closed?

Sam: Are you sure it stays off? Did you try moving the mouse while the lid was closed?

Ah, sorry, done a little more testing. It stays off indefinitely (without input) if the lid is open. But, if I run it after closing the lid, it still wakes randomly. This means that it must be receiving some imaginary input when the lid is closed to wake it.

My biggest problem is that some imaginary input wakes the laptop. Ignoring all input while the lid is closed would solve the problem. However, without a mouse connected I can't provide any input with the lid closed anyway, so this doesn't bother me as much as not waking on imaginary inputs.

I remember trying to debug this before, and the input is non-existent. The screen wakes because the X server is no longer idle, but using xev reports no input being received. It is interesting that this only happens when the lid is closed.

Perhaps this bug should be split into two parts. Firstly, a bug, that imaginary input is received randomly when the lid is closed. Secondly, a wishlist, that the screen should not wake on input while the lid is closed.

Fixing either of these would satisfy me.

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305975