GNOME Bugzilla – Bug 326552
can_suspend detection problem
Last modified: 2006-01-12 01:05:52 UTC
There might be a can_suspend detection problem. When I click Suspend from the tray icon I get the following debug messages from g-p-m: ** (gnome-power-manager:25012): DEBUG: Caught remote method exception org.freedesktop.Hal.Device.SystemPowerMana gement.NotSupported: No suspend method found ** (gnome-power-manager:25012): WARNING **: org.freedesktop.Hal.Device.SystemPowerManagement.Suspend failed (HAL error)
I get the same error Don't know why but the current code see below assumes that suspend (also hibernate) works if the property is not present in HAL. I think we should do the opposite. Furthermore in the code below the variables exists and success are very confusing. I think it would be much clearer if success was renamed to can_suspend gboolean gpm_hal_can_suspend (void) { gboolean exists; gboolean success; exists = gpm_hal_device_get_bool (HAL_ROOT_COMPUTER, "power_management.can_suspend_to_ram", &success); if (!exists) { g_warning ("[harmless]: You are not running CVS HAL " "so we will assume it's okay to suspend"); return TRUE; } /* Seeing as HAL *knows* if we can suspend, return what it thinks */ return success; }
The problem I faced with this function was that power_management.can_suspend_to_ram doesn't exist in HAL 0.5.5, so until 0.5.6 is released we can't assume this tag will give us the correct information. Before 0.5.6, we just blindly accepted that the user could suspend, so this function now does the following: If tag does not exist (e.g. < 0.5.5.1) then blindly assume we can suspend If tag does exist (0.5.6), then return it's value as hal knows best. On the other hand, seeing as we rely on HAL 0.5.6 for the Shutdown() method, and configure checks for 0.5.6, maybe we can rename this variable and the remove !exists check. Jaap, if this is what you think best, then attach a patch and I'll apply it. As for the error, "org.freedesktop.Hal.Device.SystemPowerManagement.NotSupported: No suspend method found" I'm not sure why the method would fail like that, can you try lshal |grep org.freedesktop.Hal.Device.SystemPowerManagement and see what that brings up please? This may be related to the at_console fixes that I added to HAL CVS last night, so if you could try adding permissions for your user in /etc/dbus/permissions.d/hal.conf and see if that fixes it, e.g. <!-- You can change this to a more suitable user, or make per-group --> <policy user="jaap"> <allow send_interface="org.freedesktop.Hal.Device.SystemPowerManagement"/> <allow send_interface="org.freedesktop.Hal.Device.LaptopPanel"/> <allow send_interface="org.freedesktop.Hal.Device.Volume"/> <allow send_interface="org.freedesktop.Hal.Device.Volume.Crypto"/> </policy> If you use HAL CVS, I've added a nice comment in the file saying what's happening. Or this may be a g-p-m bug :-) Thanks, Richard.
With me the error is caused because I don't have hibernate/suspend scripts installed. Debian does not have these yet :-(. So no bug in g-p-m :-) I agree that we can remove the exists flag
I've simplified the dbus stuff (and removed gpm-dbus-common.{c|h}, so can you please try now. Even without helper scripts, hal should susyend using the kernel device. Many thanks. CVS Commit: * src/Makefile.am, src/gpm-dbus-client.c, src/gpm-idle.c, src/gpm-hal.c, src/gpm-hal-callback.c, src/gpm-idle.c, src/gpm-manager.c, src/gpm-screensaver.c, src/gpm-prefs.c: Remove gpm-dbus-common from all the files. This file was originally used when the DBUS API was churning so all the changes could be done in one place. Now the glib DBUS api is stable, hardcode these simple functions in the respective places.
Fixed this in CVS. I've kept the exist part as I'm not sure if pmu.c sets the correct flags in HAL CVS. The logic is sound now tho; gboolean gpm_hal_can_suspend (void) { gboolean exists; gboolean can_suspend; exists = gpm_hal_device_get_bool (HAL_ROOT_COMPUTER, "power_management.can_suspend_to_ram", &can_suspend); if (!exists) { g_warning ("gpm_hal_can_suspend: Key can_suspend_to_ram missing"); return FALSE; } return can_suspend; } Jaap, if suspend doesn't work for you now, can you open a new bug as I think it's a HAL thing.