GNOME Bugzilla – Bug 170175
sleep button action will never usefully work
Last modified: 2009-12-16 07:06:52 UTC
Please describe the problem: do_sleep_action is called with apm as the first argument. With no arguments, apm will either print the battery status to stdout or say "No apm support in kernel". Since this successfully executes, the fallback (of blanking the screen) will never be executed. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Thanks for your bug. What would be the correct argument to use? "apm --suspend" probably? Feel free to commit that change
apm --suspend would be an improvement, but do we want to look at sending a request to HAL instead? Actually, this probably becomes more complicated with gnome-power-manager being involved...
I would suggest doing the apm change/closing that bug and then open a new enhancement request or start a discussion on the lists about using hal/gnome-power-management
Why not use hal-system-power-suspend script instead? That should work for all systems supported by HAL, not like apm --suspend. Then we can enhance it to use g-p-m dbus interface instead.
It should call g-p-m's sleep code via D-Bus. Calling "apm" is a relic from times where we didn't have this opportunity (circa 2001 or something).
It looks like g-p-m is already handling when the sleep/hibernate buttons are pressed (see gpm-button.c). So the question is: should the sleep keyboard shortcut handling in g-s-d be removed or should it somehow be reworked to mesh with g-p-s? Removing the keyboard shortcut config. would prevent people from easily assigning a custom shortcut, but then again, there's not a way to do this for hibernate currently. It seems like this would be the best option, though, as trying to handle the keyboard shortcut in two places doesn't sound very fun.
The correct thing to do would be to rip out the INPUT layer handling in gpm-button and then let g-s-d handle these. g-s-d shoudl call the g-p-m methods when these buttons are pressed. I'll rip out the code from g-p-m now.
Or maybe not. This needs discussion me thinks.
*** Bug 559572 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > The correct thing to do would be to rip out the INPUT layer handling in > gpm-button and then let g-s-d handle these. g-s-d shoudl call the g-p-m methods > when these buttons are pressed. > > I'll rip out the code from g-p-m now. > I think it's the right way. It will be really good if desktop applications get general input from X server whatever it's an ACPI input, keyboard input or any others on kernel layer. So it will be good if g-s-d maintains powerkey and make it configurable. So I think the solution is to move the code handling HAL poweroff related namespaces into g-s-d for compatibility. And let g-s-d call g-p-m methods.
(In reply to comment #8) > Or maybe not. This needs discussion me thinks. > At least we can move the code handing key press event from keyboard to g-s-d. As for lid_open, lid_down and power_button, I am sure if there is any benefits from moving them to g-s-d.
*** Bug 604330 has been marked as a duplicate of this bug. ***
Can anyone give an update at where this bug is at? Would be great to close for 2.30. Would hate to see this bug live to see its 5th birthday.
Now do_sleep_action runs "gnome-session-save --shutdown-dialog". This is not a perfect solution but is workable.
At least in upstream code it actually doesn't. Should it?
This bug's description is quite misleading. My computer has a suspend key, which is configured in g-p-m. That works. In Keyboard Shortcuts, there's another Suspend action. This one fails to work. Whether I press the Suspend key, or go to the power-down menu, and choose suspend, the effect is the same: the screen is locked, the computer suspends. This is trivial to replicate with DBus: dbus-send --session --dest=org.gnome.ScreenSaver --type=method_call /org/gnome/ScreenSaver org.gnome.ScreenSaver.Lock dbus-send --print-reply --system --dest=org.freedesktop.DeviceKit.Power /org/freedesktop/DeviceKit/Power org.freedesktop.DeviceKit.Power.Suspend The problem with binding these two commands to the Suspend action is that the dbus call for suspending has changed in the past, and will likely change more. Also, It's kind of a nuisance to represent the combined lock-suspend action in two places in the GNOME codebase.
(In reply to comment #15) > At least in upstream code it actually doesn't. Should it? Oops, my mistake. I checked my modified copy of code.
Created attachment 149770 [details] [review] Remove sleep keybindings Running "apm" -> bad It's also pretty useless because the sleep button is already handled through other means in gnome-power-manager, etc.
Comment on attachment 149770 [details] [review] Remove sleep keybindings Attachment 149770 [details] pushed as d6c3573 - Remove sleep keybindings
Created attachment 149771 [details] [review] Remove sleep key entry
Removed in master for gnome-settings-daemon and gnome-control-center.
I disagree -- having a customizable keybinding for the sleep action is not at all useless. For instance, my MacBook does not have a sleep button. I still want a keyboard shortcut for putting it to sleep. I do agree with calling apm == bad. ~a
(In reply to comment #22) > I disagree -- having a customizable keybinding for the sleep action is not at > all useless. For instance, my MacBook does not have a sleep button. I still > want a keyboard shortcut for putting it to sleep. It has a power button that'll pop up a window asking you whether you want to suspend, or go directly to suspend depending on your settings in gnome-power-manager. There's no point in making this configurable in the control-center. If you want to call another program, you can add a custom keybinding.
Ah, we hit the eternal configurability vs simplicity debate. Okay, let's have us crazy folks use custom keybindings. I just hate the fact that in order to get this functionality that way, one needs a 260-character script (above). Imagine how much the user has to want it to figure out how to do this -- somebody who doesn't hack on GNOME/DBUS will need at least 30 minutes to set this up.
Should there be separate bug opened requesting a small command line option to suspend the system. e.g. gnome-power-manager --suspend gnome-session --suspend (whatever the appropriate command would be) Also, due to the suspend command being removed from gnome-power-manager systray icon, it does leave one less avenue for user to swiftly suspend their system.
Lex, that sounds like a great idea! Would you file it for the application that's most appropriate -- I have no idea about GNOME's architecture.
(In reply to comment #25) > Should there be separate bug opened requesting a small command line option to > suspend the system. > > e.g. > gnome-power-manager --suspend > gnome-session --suspend > (whatever the appropriate command would be) > > Also, due to the suspend command being removed from gnome-power-manager systray > icon, it does leave one less avenue for user to swiftly suspend their system. Or you can just use dbus-send to send Susppend command to devicekit-power.