Version: (using KDE 4.2.90) Installed from: SuSE RPMs Since i am using 4.3 RC1 i cannot go to s2ram or s2disk using the buttons for them. When clicking them nothing happens. Going to s2ram via command still works.
I confirm that although my system supports suspend, the two suspend buttons in kicker in KDE4.3 don't work at all. This is a new computer however, so I can't say if it worked in 4.2.
I can confirm this, too. This is not working sind kde4.1, better to say: since powerdevil. I found out that the key-combination for suspend-to-ram (which is on my notebook "Fn+F4" has no effekt. Pressing it, nothing happens. Also suspend-to-ram is working, when using the plasmoid "Accuwatch". With kpowersave it worked perfectl. I also found out: Syslog shows, that there is no keycode for "Fn+F4" available/in use. ------------ Syslog says: Nov 16 19:39:04 localhost logger: acpid: action SBTN is not defined There are also other keycodes no more available, but it might be, that this has nothing to do with this bug. -------- Syslog also tells me: Nov 16 19:39:47 localhost logger: acpid: action FNDEL is not defined Nov 16 19:39:47 localhost logger: acpid: action FNDEL is not defined Nov 16 19:39:48 localhost logger: acpid: action FNPGDOWN is not defined Nov 16 19:39:50 localhost last message repeated 3 times Nov 16 19:39:52 localhost logger: acpid: action FNDEL is not defined Nov 16 19:39:55 localhost last message repeated 3 times Nov 16 19:39:58 localhost logger: acpid: action FNPGDOWN is not defined Nov 16 19:40:01 localhost last message repeated 3 times Nov 16 19:40:03 localhost logger: acpid: action FNDEL is not defined Nov 16 19:40:07 localhost last message repeated 7 times ---------- showkey -m is telling me this: LANG=C showkey -m kb mode was RAW (Warning: Currently running in a pseudoterminal.) The reported keycodes are probably wrong. press any key (program terminates after 10s of last keypress)... keycode 96 release keycode 95 press ---------- I hope this helps. I closed bugreport #210575 and #214866 as they are a double of this bug. Thanks for any help. Regards Hans-J. Ullrich
*** Bug 214866 has been marked as a duplicate of this bug. ***
In openSuse 11.2 with kde 4.3.3 all works well for me.
I've got the same problem. Running the "hibernate" script or echoing "mem" to /sys/power/state will both suspend to RAM. Running "solid-powermanagement query suspend" returns "to_ram". But if I actually run "solid-powermanagement suspend to_ram", the process just sits around doing nothing until I kill it.
Hi there, For the issue with the suspend buttons in the GUI not working let's just say, that I had the same issue and I got it fixed. So, does this command work if executed as user? dbus-send --system --print-reply --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0 If it doesn't try it as root user or via sudo. If you can suspend using this command as root but not as a normal user, then you have a rights issue. Then there are a couple of things to check. If your distros are using consolekit there are a couple of things to check: - Is consolekit running? - Is it started early enough in the boot process?(A sign of this if restarting HAL makes the suspend buttons work) - Is consolekit notified about your session?(the output of ck-list-sessions is helpful here) - Is your user in a group that has enough rights?(on Ubuntu it's admin, for most other distros it's probably wheel) - Is this group allowed by PolicyKit to make changes to powermanagement?(see /etc/PolicyKit/PolicyKit.conf) Hope I could help, as this issue is particular hard to nail down...
Ah, I forgot, for the issue that Powerdevil is not reacting to the Suspend keyboard keys, see this Bug report here: https://bugs.kde.org/show_bug.cgi?id=181444
(In reply to comment #6) > For the issue with the suspend buttons in the GUI not working let's just say, > that I had the same issue and I got it fixed. > So, does this command work if executed as user? > > dbus-send --system --print-reply --dest=org.freedesktop.Hal > /org/freedesktop/Hal/devices/computer > org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0 That helped me track down the problem. HAL uses the pm-utils package to suspend/hibernate, and I didn't have it installed. Suspending as root and user both work fine now. Even though the problem was lower down than KDE, it would have been nice to have KDE report the error from DBUS: "Error org.freedesktop.Hal.Device.SystemPowerManagement.NotSupported: No suspend method found".
Hmm. Looks like I spoke too soon. Suspending works fine now when initiated on the command line by solid-powermanagement, but still doesn't work from the GUI. Even after logging out and back in.
In 4.6 the behavior should be more consistent and explainatory if a package is missing, hence I'm closing the bug
Still a problem with 4.6.0. Selecting "suspend to ram" in the "leave" box still results in absolutely nothing: no error message, no suspend. And the solid-powermanagement command apparently doesn't exist anymore, so I can't even suspend the system that way anymore. Running pm-suspend works fine, though.
I am closing this bug as downstream: suspend works reliably on KDE, although some distributions used to ship broken policies which prevented KDE from doing that. Nowadays, it should be fixed in every modern distro.