GNOME Bugzilla – Bug 565661
When laptop lid is closed on battery does not suspend as expected
Last modified: 2012-11-19 21:08:59 UTC
Please describe the problem: When closing the laptop lid whilst on battery power, the computer should suspend, but does not. Steps to reproduce: 1. Use battery power 2. Close lid 3. Actual results: Screen is turned off, but computer not suspended. Expected results: I expect the computer to suspend. Does this happen every time? Yes Other information: Backlight brightness is not reduced when on battery power either.
Relevant downstream Ubuntu bug with more information: https://bugs.launchpad.net/gnome-power/+bug/44058
Created attachment 129878 [details] Gnome Power Manager verbose log
Created attachment 129879 [details] Gconf custom settings
Created attachment 129880 [details] Hald verbose log (part1)
Created attachment 129881 [details] Hald verbose log (part2)
I have collected some information from my system (Sony Vaio VGN-SZ71WN). I used this page as a guide: http://projects.gnome.org/gnome-power-manager/bugs.html Suspend manually from the battery icon or logout menu on Ubuntu works fine for me, its only on closing the laptop lid that nothing happens. root@lappy:~# gnome-power-manager --version Version 2.24.2 root@lappy:~# dbus-daemon --version D-Bus Message Bus Daemon 1.2.12 Copyright (C) 2002, 2003 Red Hat, Inc., CodeFactory AB, and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. root@lappy:~# hald --version HAL package version: 0.5.12 root@lappy:~# uname -a Linux lappy 2.6.28-8-generic #26-Ubuntu SMP Wed Feb 25 04:28:54 UTC 2009 i686 GNU/Linux Distribution: Ubuntu Jaunty 9.04 (development) I've attached a gnome-power-manager verbose trace. When closing and opening the laptop lid nothing is logged. I'm also attaching my GConf custom settings. $ cat /var/log/messages | grep gnome-power-manager produces nothing on my system. I've also attached my HAL verbose log. I closed and opened the laptop lid a few times while this was running, there was far too much constant output for me to notice if anything relevent was logged though. When I run lshal -m and close and open the lid, nothing is logged. As I noted in the Ubuntu bug though, /proc/acpi/button/lid/LID0/state is always correct.
Created attachment 134621 [details] [review] Patch to fix the issue
It's too late for me to test the patch, but I think this should fix it. I see no reason to ignore the sleep timeout if the lid is closed, so the patch just takes this into account. Note that the patch is for 2.24, but it's trivial to port it to 2.26: just replace GPM_IDLE_MODE_SYSTEM with GPM_IDLE_MODE_SLEEP ;-)
Created attachment 134640 [details] [review] test patch Isn't this a better fix?
Richard: assuming that we can only go from DIM to BLANK or SLEEP, from BLANK to SLEEP, and from SLEEP to NORMAL, this makes sense, indeed. Not sure the assumption is right in the code (but I guess it's right in theory) ;-)
(In reply to comment #10) > Richard: assuming that we can only go from DIM to BLANK or SLEEP, from BLANK to > SLEEP, and from SLEEP to NORMAL, this makes sense, indeed. No, the state diagram looks like this: .-->NORMAL | | | \/ \---DIM | | | \/ \--BLANK | | | \/ \--SLEEP So when a sleep state gets cleared, it always goes back to NORMAL. Does this make sense?
Yeah, right. I was just wondering if there's any weird case where we could go from BLANK to DIM, for example. But if there are, they should get fixed, I guess ;-)
I'm the reporter of http://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/376793 , and trying to track down the source of my issue. Neither of these patches fixed the problem for me. Has it corrected the problem for anyone else? (If so, I'm likely looking at a different issue...)
More info :- Now at gnome-power-manager-2.24.4-1.fc10.i386 (Fedora 10 i386) kernel - 2.6.27.24-170.2.68.fc10.i686 SMP Laptop can suspend/hibernate when selected manually. Does not automatically:- 1. dim screen as requested in setup (if power cord unplugged) 2. hibernate automatically when laptop lid closed (requested to do this in gnome power manager setup gui) Haven't tested shutdown when battery critically low. HAL (?) _can_ see when power cord is plugged and unplugged. I have no debug code on this machine. Is there anything you would like me to do to test any changes?
More info:- 1. removed power cord 2. manually suspended 3. restarted 4. screen has now been dimmed 5. closed lid (still on battery power) 6. machine hibernated as expected 7. restarted machine 8. screen still dimmed 9. inserted power cord 10. screen undimmed as expected 11. removed power cord 12. gui notifies that machine now on battery 13. screen _not_ dimmed as expected end of test
This also causes another problem: the display doesn't go to blank automatically after a certain idle time. The following appears in the output when I run gnome-power-manager with verbose mode: "lid is closed, so we are ignoring ->NORMAL state changes" It assumes that the lid is closed and, because of that, it ignores any change of the display mode. (Of course, the message appears when I move the mouse. But it helps to show that it is ignoring the state changes.) It works well until the lid is closed for the first time. After that, it always assumes that the lid is closed.
I also noticed another thing. If I do the following it recognizes correctly if the lid is closed or open. (with the lid closed) $ cat /proc/acpi/button/lid/LID/state state: closed (with the lid open) $ cat /proc/acpi/button/lid/LID/state state: open But the output of the gnome-power-manager in verbose mode, with the lid open, says that the lid is closed: TI:12:09:52 TH:0x8a7e8b8 FI:gpm-idle.c FN:gpm_idle_set_mode,108 - Doing a state transition: normal TI:12:09:52 TH:0x8a7e8b8 FI:gpm-manager.c FN:gpm_manager_idle_changed_cb,804 - lid is closed, so we are ignoring ->NORMAL state changes TI:12:09:52 TH:0x8a7e8b8 FI:gpm-idle.c FN:gpm_idle_evaluate,192 - X not idle
Vincent, Richard, this bug report is very old and the patch has been bitrotting for 3 years. Should this report be marked obsolete?
So I guess this is OBSOLETE by now. Please reopen if it's not.