Bug 507547

Summary: laptop suspend two times after wake up
Product: [Fedora] Fedora Reporter: Jan Drábek <repli2dev>
Component: gnome-power-managerAssignee: Richard Hughes <richard>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: leo, mschmidt, richard, will
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-25 11:28:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Gnome power manager verbose log none

Description Jan Drábek 2009-06-23 09:35:09 UTC
Description of problem:
If I suspend laptop with FN+F4 (thinkpads have this one) then after waking laptop up it fall asleep again and even one more. Other way of suspending (pm-suspend or from gnome-power-manager icon in systray) are not affected and work as expected.

Version-Release number of selected component (if applicable):
Problem started after upgrading DeviceKit-power to version 008, and disappear after downgrade.

This problem is related with 497563

How reproducible:
always

Steps to Reproduce:
1. Suspend laptop via keyboard shortcut (FN+F4)
2. Wake laptop up - power button / opening lid
3. Fall asleep
4. Wake it again
5. Fall asleep
6. Wake it for the last time
  
Actual results:
suspend two times more than should be acceptable

Expected results:
Laptop should suspend only once.

Additional info:

Comment 1 Will Kemp 2009-06-24 14:01:32 UTC
I'm experiencing the same thing.

Lenovo Thinkpad R61.

Comment 2 Michal Schmidt 2009-06-24 15:38:13 UTC
Interesting. Jan's Thinkpad is an R61 too. (He said so in https://bugzilla.redhat.com/show_bug.cgi?id=497563#c17)

Comment 3 Michal Schmidt 2009-06-24 17:09:54 UTC
It would be interesting to see what g-p-m thinks it's doing.
Please do this:
$ killall gnome-power-manager
$ GPM_VERBOSE=1 gnome-power-manager > /tmp/g-p-m.log
Then press Fn+F4.
After wakeup attach the resulting /tmp/g-p-m.log here.

Comment 4 Jan Drábek 2009-06-24 17:25:22 UTC
Created attachment 349281 [details]
Gnome power manager verbose log

Here it is.

Comment 5 Michal Schmidt 2009-06-24 21:21:44 UTC
OK, it seems gnome-power-manager indeed asks DeviceKit-power to suspend again right after waking up (at time 19:21:12 in the log). DeviceKit-power just obeys.
Moving this bug to gnome-power-manager.


The first suspend is in reaction to the button event:
TI:19:20:43	TH:0x16c96f0	FI:gpm-button.c	FN:gpm_button_filter_x_events,129
 - Key 150 mapped to key suspend
TI:19:20:43	TH:0x16c96f0	FI:gpm-button.c	FN:gpm_button_emit_type,89
 - emitting button-pressed : suspend
TI:19:20:43	TH:0x16c96f0	FI:gpm-manager.c	FN:button_pressed_cb,876
 - Button press event type=suspend

The subsequent (undesirable) button event after wakeup looks different:
TI:19:21:12	TH:0x16c96f0	FI:gpm-backlight.c	FN:gpm_backlight_button_pressed_cb,404
 - Button press event type=suspend
TI:19:21:12	TH:0x16c96f0	FI:gpm-button.c	FN:hal_device_condition_cb,407
 - condition=ButtonPressed, details=sleep
TI:19:21:12	TH:0x16c96f0	FI:gpm-button.c	FN:gpm_button_emit_type,89
 - emitting button-pressed : sleep
TI:19:21:12	TH:0x16c96f0	FI:gpm-manager.c	FN:button_pressed_cb,876
 - Button press event type=sleep

Comment 6 Michal Schmidt 2009-06-24 22:18:19 UTC
Does this build of gnome-power-manager make any difference?:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1434426
It contains Matthew Garrett's patch from bug 497743 of which this one is probably a duplicate.

Comment 7 Will Kemp 2009-06-25 05:14:35 UTC
That appears to have fixed it for me.

Comment 8 Jan Drábek 2009-06-25 10:44:54 UTC
I can confirm that the problem disappear after installing gnome-power-manager-2.26.2-1.fc11.bz497743.x86_64.rpm from address.

Thanks

Comment 9 Michal Schmidt 2009-06-25 11:28:39 UTC

*** This bug has been marked as a duplicate of bug 497743 ***