GNOME Bugzilla – Bug 331448
laptop does not suspend on lid close when configured to do so if plugged in; explicit suspend works
Last modified: 2006-02-18 19:20:51 UTC
Please describe the problem: (Richard requested I open a new bug as I had no permission to reopen bug 329512, which was his first desire) When configured to suspend on lid close, the backlight and screen are turned off via DPMS, but no suspend is attempted. Selecting 'suspend' from the dropdown does suspend the machine on lid close. Hibernate is also broken in the same way. I am told this is intentional behavior to cater to users with laptop docking stations. I do not own a docking station. I submit the following two comments on why this situation is unsatisfactory: 1: The dialog plainly says 'lid close: suspend', I close the lid, it doesn't suspend. There is no fine print anywhere that explains the option really means 'suspend on odd tuesdays, but only if I feel like it' or perhaps more accurately, 'I am more clever than you and will not do what you've explicitly configured me to do.' 2: on a more literally flamey note, there are a number of laptops out there that will bake themselves if left fully powered on with the lid closed. Early iBooks are the most famous example of this, but other cheaper laptops have the same problem. I do not suggest taking away functionality from the docking station users; their request for conditional behavior is reasonable. However, it should not overload an existing option that second-guesses users without warning. I am technically savvy yet wasted a workday on the process of discovering the behavior of my computer disobeying without warning was intentional. Steps to reproduce: 1. Under preferences, set lid close behavior to 'suspend' 2. Close preferences 3. close laptop lid with laptop plugged in. Actual results: Absolutely nothing. Well, my computer disobeys me, thus pissing me off. :-) Expected results: Computer suspends, as explicitly configured. Does this happen every time? Yes Other information: Original running commentary at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180654
This sounds reasonable to me. I'd expect my laptop to suspend if I close the lid even if it is plugged in. I don't have a dock though. Is is possible to detect the dock and/or an external monitor?
I don't think so, unless you've got an IBM thinkpad... mgj59 is doing some work with acpi to detect more stuff, but it's all so broken. What do you suggest we do with the pref pane, split up the "When lid closed on AC" and "When lid closed on Battery" or just a checkbox "Don't do this action if on AC power"?
Both are fine, so long as it is clear what will happen and it's easy for the user to understand how to make it do what they want.
Just to throw in my few cents: * The pref needs to die, period. Really, the big issue that we have prefs for is that suspend is flaky for a lot of users. Perhaps instead of a bunch of prefs, we just need a pref "My suspend is fucked", if checked, it doesn't do anything, if unchecked it makes things "just work" (or perhaps we could add "None" to the sleep type pref). Then this bug is rendered moot, since it doesn't say explicitly that we will suspend when the lid is closed. It suspends most of the time with lid closed, but doesn't with AC power. Will the typical user care? * Laptops that bake themselves, probably have been baking themselves for a while since we're just now getting suspend working, and its still not always reliable.
> Will the typical user care? No, I'm just reporting the bug because biting my nails had gotten too boring. > Laptops that bake themselves, probably have been baking themselves for a > while since we're just now getting suspend working, and its still not always > reliable. It was solid for me for a year until I installed Rawhide. I see no reason to rationalize this failure. Users could always go back to Ubuntu where suspend/hibernate work :-P
This is quite a big deal for me: my Fujitsu laptop doesn't have a suspend button - so the only convenient way to suspend is by closing the lid (Fujitsu sets up XP to do just this when shipped). So, the previous functionality was just what I wanted, and now it's gone. Side note: the new behaviour is is even more confusing since "1. Close lid, 2. Pull plug" leaves laptop on, while "1. Pull plug, 2. Close lid" suspends.
My intention was to have g-p-m suspend if lid was closed while powered, and then AC was removed. My intial comment to that bug as well as later comments noted that. The lack of that behavior certainly clouds things further.
For reference, I just filed bug 331655.
2006-02-18 Richard Hughes <richard@hughsie.com> * data/gnome-power-manager.schemas.in: Make action_button_lid different policy values for AC and battery. Default to suspend for on battery and nothing for on AC. * src/gpm-prefs.h, src/gpm-prefs.c (setup_battery_actions, setup_ac_actions): Set the new policy keys individually. * src/gpm-prefs.c (gpm_prefs_setup_action_combo): Add the default action of nothing if gconf is missing. Stops a blank combobox, and makes it easier for us to debug without installing new schema each time. * src/gpm-manager.c (lid_button_pressed): do the new action when lid is closed and on AC power. Fixes (#331448) Hope this finishes the argument. Lots of different people use thier laptop power options in very different ways, and I think we should allow an extra combobox to allow them to set policy. This is a very emotive issue on both sides, and I appreciate all your points of view, thanks. Richard.
Honestly, I feel this is worse than the way it was originally, prior to bug 329512 being fixed. What good is something called a power manager, if it automatically doesn't manage power for you? See <http://log.ometer.com/2005-09.html>. Pick a good default, and let's go with that. The general user is only going to get confused with this, and its not something we should really have in the prefs at all. I feel that this is/was only a point of contention because of 2 issues I already foresaw but weren't addressed properly: 1. The pref wording was misleading once the initial patch to bug 329512 was committed. 2. If you were plugged in, closed the lid, and then removed AC, the laptop would not suspend. I see the possible solutions as follows: 1. Revert BOTH the original change and this change, tell me g-p-m is not for me. g-p-m will suspend on every lid close. I am not in g-p-m's target audience, and that is fine as long as I know it. 2. Fix the pref wording to reflect the change, AND make the laptop suspend when unplugged if lid is closed. This will reduce confusion from those who want to know why the computer doesn't do what it says it will do. Users who really want to suspend every lid close while on AC are probably outside of g-p-m's target audience. There is still the way of doing this manually. 3. These prefs are still silly, IMO. Again, the only major thing that users typically care about is: "will I be fucked if the laptop auto suspends?" In a lot of cases, that is yes, which is AFAICT the only reason that g-p-m still has prefs. The only pref should be "Suspend works for me" until it works reliably for pretty much everyone in which case even that pref can go away.
Callion, we have good defaults, but the issue is that people want to change the defaults to what best suits thier lifestyle. Should a Power Manager be a help or a hinderance? If I told my girlfriend that she had to unlock her screen with her password every time she shut the lid of the laptop she would tell me very loudly "Why? It's my laptop!", but for me, leaving my laptop unlocked would be a very bad thing. I know we want a "simple" solution, but I think we have to be flexable. > I am not in g-p-m's target audience g-p-m should be a generic tool -- if stuff like gnome-screensaver depends on g-p-m functionality then it can't easily be removed from a system. People often have very strong views on power-management (as I've found in the last year or so) and no two people want the same thing. I think the best we can do if choose really good defaults, leaving the medium-to-expert users to explore g-p-p and start changing things exactly how they like. I agree with your case of removing the ac-adapter and suspending, it's easy to do in the present framework. And the screen locking thing still needs some more work. Richard.
Believe it or not, people have strong views about their networking too, as I've learned working on NetworkManager. There are people who want to do things with their network that go against NetworkManager's design goals. But it is important that we have design goals. I'm extremely proud that NetworkManager has no real prefs, and no pref panel at all. And networking is arguably more complex than suspending and resuming a laptop since it has so much that needs to be handled. Some people disagree with the way it manages it, but we tend to aim for the typical user: the power user can figure out how to change things manually if they really want to. You're right. g-p-m should be generic. But if this change interferes with gnome-screensaver, then I maybe g-p-m is not generic enough. All g-p-m needs to do is tell apps that "we're about to suspend, hurry up and do stuff", or maybe expose a plugin interface for apps to hook into. I'm not really sure why g-p-m needs to do the locking itself.
> I'm extremely proud that NetworkManager has no real prefs, and no pref panel at all. Yes, and it rocks. But people always have the fallback of gnome-networking-tool (or whatever it's called) and system-config-networking which doesn't really have a parallel with g-p-m. >I'm not really sure why g-p-m needs to do the locking itself. A valid point, but then something has to do the locking...