g-p-m assumes that suspend is synchronous, but devicekit-power makes a g_spawn_command_line_async() call. The long term ideal might be to send a resume signal when the system has resumed (determined by pm-suspend exiting) and refactoring g-p-m to deal with that, but in the short term just making it synchronous should do. The dpk-client code probably needs to ignore the error returned if it's a timeout.
commit dccd5fc898bcb3d66038902cfddeb9ea935f5a18 Author: Richard Hughes <richard> Date: Sat Apr 25 11:07:30 2009 +0100 Ignore method timeouts when we suspend and hibernate :100644 100644 045c6d7... 859a8be... M devkit-power-gobject/dkp-client.c commit 6b197ebd5e0f914071a03f5e3da21e9045df12bc Author: Richard Hughes <richard> Date: Sat Apr 25 11:06:52 2009 +0100 Make the suspend and hibernate scripts execute synchronously. Fixes rh#497563 :100644 100644 fdcd21e... bcc6504... M src/dkp-daemon.c
Could you please test the packages here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1320198 Thanks.
This works, but I'm now seeing double suspends when I hit the sleep key. I'm guessing that this is due to g-p-m not processing the hal event until after resume now (as it's blocked in performing the suspend), and so too much time has passed between them for it to be handled by the de-duplication. Is there any reason for us to listen to hal at all for sleep or hibernation button presses?
Confirmed that building gnome-power-manager without --enable-legacy-keys fixes this for me, so from the DeviceKit-power point of view this is fixed in the koji build.
(In reply to comment #4) > Confirmed that building gnome-power-manager without --enable-legacy-keys Then we get no lid events. :-( Richard.
Ok. So perhaps we should just ignore button (rather than switch) events from hal. I'll open a g-p-m bug for this.
Is it insane to add a property lid-is-closed to DeviceKit-power? I can't think of a better place for the lid status information, and don't really want to add low level /dev/input type stuff to g-p-m. If I'm adding lid-is-closed, would SW_TABLET_MODE, SW_HEADPHONE_INSERT and SW_RADIO also needed to be handled? I can't help thinking this is feature bloat, and should probably be exposed in Xorg or something. Ideas welcome.
Switches can't be exposed in Xorg until XInput 2 - there's simply nothing in the protocol to let us deal with them. I think this is simply going to be a case of needing Hal until the rest of the stack catches up. Unless we add a DeviceKit-input.
Upstream can now use the lid-is-closed property in DeviceKit-power -- we just have to fix this for F11. I'm thinking of including your hacky patch to g-p-m, and tagging the sync DeviceKit-power. Does that sound like a plan?
DeviceKit-power-008-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/DeviceKit-power-008-1.fc11
DeviceKit-power-008-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update DeviceKit-power'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-5728
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Installing this update actually breaks suspend - after waking up laptop go asleep again... (and twice more)... Btw. this bug seems to be related with 497655
DeviceKit-power-008-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
As I said yesterday - this update BREAK suspend! Now it is suspending three times!
(In reply to comment #15) > As I said yesterday - this update BREAK suspend! Now it is suspending three > times! Different bug, different component. Have you tried updating gnome-power-manager?
I don't suppose so. Firstly, I completed today's update and try it again - the problem persist. Then, I tried downgrade only DeviceKit-power (to version 0.1.20090401git.fc11) and the problem just disappeared. So, please consider that, thanks. Btw. My laptop is Thinkpad R61.