Bug 181444 - powerdevil should listen to XF86Sleep
Summary: powerdevil should listen to XF86Sleep
Status: RESOLVED FIXED
Alias: None
Product: solid
Classification: Frameworks and Libraries
Component: powermanagement-daemon (show other bugs)
Version: unspecified
Platform: Compiled Sources Unspecified
: NOR normal
Target Milestone: ---
Assignee: Dario Freddi
URL:
Keywords:
: 182538 186368 245032 245463 247018 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-21 00:55 UTC by Armin Berres
Modified: 2011-02-19 13:22 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Global hotkey definition mapping the Sleep key to a org.freedesktop.PowerManagement.Suspend dbus call (763 bytes, text/plain)
2010-02-28 11:26 UTC, Fabian Moser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Armin Berres 2009-01-21 00:55:58 UTC
Version:            (using Devel)
Installed from:    Compiled sources

When I press "shutdown key" (Fn+Moon) on my notebook XF86Sleep is emitted, but powerdevil does not put the notebook to S3.
With xev I can see that everything should be fine:

KeyRelease event, serial 62, synthetic NO, window 0x4c00001,
    root 0x8b, subw 0x0, time 8896913, (97,93), root:(102,118),
    state 0x0, keycode 150 (keysym 0x1008ff2f, XF86Sleep), same_screen YES,
    XLookupString gives 0 bytes:                                           
    XFilterEvent returns: False

In the profiles "When sleep button is pressed: Suspend to Ram" is selected.
Comment 1 Andrew M 2009-02-06 08:19:00 UTC
This feature is very much needed for the many users who's suspend button doesn't work properly with acpid yet suspends from the command line.
Comment 2 Olaf Lenz 2009-03-11 11:56:56 UTC
I want to confirm this. Needless to say, the same goes for XF86Standby.
Comment 3 Chris Bainbridge 2009-03-11 13:05:08 UTC
There is a temporary workaround here: http://linuxbasement.com/content/when-powerdevil-does-not-recognize-suspend-button-kde-42

Obviously it would be nice to see this fixed properly.
Comment 4 Olaf Lenz 2009-03-11 13:29:15 UTC
Hmm. I had already tried this kind of workaround. Unfortunately, KDE (or rather Qt) doesn't seem to able to recognize the key XF86Sleep in the first place. I.e., when I try to assign the corresponding key to a command, I get the message "Qt doesn't support the key you just pressed." 
So I think the problem might be deeper buried in Qt than the Powerdevil.
Comment 5 Olaf Lenz 2009-03-11 14:20:05 UTC
Given the above workaround, it seems that there are actually two bugs involved:
* Powerdevil doesn't handle the key XF86Sleep or XF86Standby correctly, however, Qt/KDE is able to recognize the key correctly.
* Under some circumstances, Qt doesn't seem to be able to recognize the key at all.

This bug report is more focussed on the first bug. Should I file the second one as a separate bug?
Comment 6 Chris Bainbridge 2009-03-11 15:07:23 UTC
kpowersave recognises the suspend key and responds appropriately, though maybe it is listening for HAL events or something rather than keypress events. It also has some other problems with kde4...
Comment 7 Todd Partridge 2009-11-13 05:13:06 UTC
I can confirm this on Arch Linux (stock KDE 4.3.3).  Unable to fix in the above workaround because I'm guessing that Powerdevil has already bound to the Sleep button.  I updated the workaround a bit (though I had to use a different button): http://linuxtidbits.wordpress.com/2009/11/12/sleep-button-in-kde-4-workaround/
Comment 8 Dario Freddi 2009-12-01 18:19:24 UTC
*** Bug 186368 has been marked as a duplicate of this bug. ***
Comment 9 David Greengas 2009-12-01 23:51:41 UTC
I decided out of the blue to attempt this in 4.3.3

In the past I had a custom xbindkeys script to run a dbus command to enable sleep. I have been using that for almost a year and did not think to change.

I disabled my script and tried the XF86Sleep keyboard key and it worked!

Can someone else confirm this in 4.3.3?
Comment 10 Dario Freddi 2009-12-02 00:24:40 UTC
I think the resolution is probably thanks to Qt, since it's probably Qt's fault for not recognizing that button. Would you mind sharing your Qt version and eventual patches applied to it?
Comment 11 Andrey Borzenkov 2009-12-02 04:47:56 UTC
There is royal mess with these keys. My notebook generates XF86Suspend when I press sleep (Moon) button which is silently ignored. Should I open separate bug report for every key or can it be handled here?

KDE 4.3.77/Qt 4.6.0
Comment 12 Todd Partridge 2009-12-02 05:16:35 UTC
Tried several workarounds and still can't get this fixed.  Anyone have any ideas?
Comment 13 David Greengas 2009-12-02 17:51:56 UTC
I spoke too soon on previous post. It does not work with KDE only. I really think it is a solid issue since solid is responsible for passing the sleep keystroke to powerdevil. Solid is not passing the keystroke.

My working solution is as follows:
install xbindkeys -- it will pick up keystrokes before getting passed to kde
create an executable shell script (I put mine in ~/bin) called solidsuspend with the following contents:
#!/bin/bash
solid-powermanagement suspend 'to_ram'

Then update your .xbindkeysrc with the following entry
"~/bin/solidsuspend"                                      
  XF86Sleep  
-- If the moon button corresponds to key XF86Suspend, then replace that above -- check out using cli app xev to get the keystroke.
Then ensure that xbindkeys is running at session startup.
That's it.
Comment 14 Todd Partridge 2009-12-03 00:22:28 UTC
Thanks David, got it working.  Definitely will do for now.
Comment 15 Michael Jansen 2009-12-07 22:32:53 UTC
SVN commit 1060011 by mjansen:

Add new X11 Qt keys to KKeyServer
=================================

From http://reviewboard.kde.org/r/1950

Patch by Felix Geyer

If some of the bugs are not fixed by this patch please reopen. I couldn't
test most of them because i naturally have all of the keyboards / keys
available.

BUG: 166423
BUG: 180602
BUG: 182349
BUG: 182672
BUG: 183163
BUG: 183583
BUG: 183726
BUG: 192704
BUG: 196570
BUG: 205869
BUG: 212220

CCBUG: 181444
    The sleep button is now supported. Please close if fixed.

ADDED KEYS

XF86XK_AddFavorite 0x1008FF39
XF86XK_ApplicationLeft 0x1008FF50
XF86XK_ApplicationRight 0x1008FF51
XF86XK_AudioCycleTrack 0x1008FF9B
XF86XK_AudioForward 0x1008FF97
XF86XK_AudioRandomPlay 0x1008FF99
XF86XK_AudioRepeat 0x1008FF98
XF86XK_AudioRewind 0x1008FF3E
XF86XK_Away 0x1008FF8D
XF86XK_BackForward 0x1008FF3F
XF86XK_Battery 0x1008FF93
XF86XK_Bluetooth 0x1008FF94
XF86XK_Book 0x1008FF52
XF86XK_BrightnessAdjust 0x1008FF3B
XF86XK_Calculater 0x1008FF54
XF86XK_Calendar 0x1008FF20
XF86XK_CD 0x1008FF53
XF86XK_Clear 0x1008FF55
XF86XK_ClearGrab 0x1008FE21
XF86XK_Close 0x1008FF56
XF86XK_Community 0x1008FF3D
XF86XK_ContrastAdjust 0x1008FF22
XF86XK_Copy 0x1008FF57
XF86XK_Cut 0x1008FF58
XF86XK_Display 0x1008FF59
XF86XK_Documents 0x1008FF5B
XF86XK_DOS 0x1008FF5A
XF86XK_Eject 0x1008FF2C
XF86XK_Excel 0x1008FF5C
XF86XK_Explorer 0x1008FF5D
XF86XK_Finance 0x1008FF3C
XF86XK_Game 0x1008FF5E
XF86XK_Go 0x1008FF5F
XF86XK_Hibernate 0x1008FFA8
XF86XK_History 0x1008FF37
XF86XK_HotLinks 0x1008FF3A
XF86XK_iTouch 0x1008FF60
XF86XK_KbdBrightnessDown 0x1008FF06
XF86XK_KbdBrightnessUp 0x1008FF05
XF86XK_KbdLightOnOff 0x1008FF04
XF86XK_LightBulb 0x1008FF35
XF86XK_LogOff 0x1008FF61
XF86XK_MailForward 0x1008FF90
XF86XK_Market 0x1008FF62
XF86XK_Meeting 0x1008FF63
XF86XK_Memo 0x1008FF1E
XF86XK_MenuKB 0x1008FF65
XF86XK_MenuPB 0x1008FF66
XF86XK_Messenger 0x1008FF8E
XF86XK_MonBrightnessDown 0x1008FF03
XF86XK_MonBrightnessUp 0x1008FF02
XF86XK_Music 0x1008FF92
XF86XK_MySites 0x1008FF67
XF86XK_News 0x1008FF69
XF86XK_OfficeHome 0x1008FF6A
XF86XK_Option 0x1008FF6C
XF86XK_Paste 0x1008FF6D
XF86XK_Phone 0x1008FF6E
XF86XK_Pictures 0x1008FF91
XF86XK_PowerDown 0x1008FF21
XF86XK_PowerOff 0x1008FF2A
XF86XK_Reload 0x1008FF73
XF86XK_Reply 0x1008FF72
XF86XK_RotateWindows 0x1008FF74
XF86XK_RotationKB 0x1008FF76
XF86XK_RotationPB 0x1008FF75
XF86XK_Save 0x1008FF77
XF86XK_ScreenSaver 0x1008FF2D
XF86XK_Select 0x1008FFA0
XF86XK_Send 0x1008FF7B
XF86XK_Shop 0x1008FF36
XF86XK_Sleep 0x1008FF2F
XF86XK_Spell 0x1008FF7C
XF86XK_SplitScreen 0x1008FF7D
XF86XK_Subtitle 0x1008FF9A
XF86XK_Support 0x1008FF7E
XF86XK_Suspend 0x1008FFA7
XF86XK_TaskPane 0x1008FF7F
XF86XK_Terminal 0x1008FF80
XF86XK_Time 0x1008FF9F
XF86XK_ToDoList 0x1008FF1F
XF86XK_Tools 0x1008FF81
XF86XK_TopMenu 0x1008FFA2
XF86XK_Travel 0x1008FF82
XF86XK_UWB 0x1008FF96
XF86XK_Video 0x1008FF87
XF86XK_View 0x1008FFA1
XF86XK_WakeUp 0x1008FF2B
XF86XK_WebCam 0x1008FF8F
XF86XK_WLAN 0x1008FF95
XF86XK_Word 0x1008FF89
XF86XK_WWW 0x1008FF2E
XF86XK_Xfer 0x1008FF8A
XF86XK_ZoomIn 0x1008FF8B
XF86XK_ZoomOut 0x1008FF8C

 M  +243 -52   kkeyserver_x11.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1060011
Comment 16 Jonathan Thomas 2009-12-12 04:14:49 UTC
In KDE 4.4, the key is recognized by Qt and KDE (I can assign it to shortcuts, etc), but Powerdevil still needs to listen for the key and sleep when it hears the key, for the cases where hardware doesn't handle the suspend key. (perhaps using a KAction so that it isn't hardcoded/can be configurable.)
Comment 17 Fabian Moser 2010-02-28 11:26:59 UTC
Created attachment 41193 [details]
Global hotkey definition mapping the Sleep key to a org.freedesktop.PowerManagement.Suspend dbus call

Importing the attached file in the Input Actions view of the System Settings results in the desired behaviour. However, I can't judge the universality of this solution.
Comment 18 Chris Desjardins 2010-06-18 17:51:42 UTC
Hi I am just wondering what the status of this bug report is? I have a Lenovo X301 my suspend key is not working as of kde 4.4.4.  

From xev for suspend:

KeyRelease event, serial 31, synthetic NO, window 0x1e00001,
    root 0xae, subw 0x0, time 3108384, (1072,690), root:(1076,713),
    state 0x0, keycode 150 (keysym 0x1008ff2f, XF86Sleep), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Also, I don't know if this is related but when I close my laptop screen, my laptop does not go to sleep. This would be expected behavior and I can open a separate bug report if appropriate.
Comment 19 Chris Desjardins 2010-06-18 18:01:59 UTC
I just wanted to mention that Fabian Moser's attachment in Comment #17 works here for my Lenovo x301. fn+f4 suspends my laptop as it should.
Comment 20 Florian Goth 2010-08-07 21:09:50 UTC
I have the same issue on my X201 on Sabayon Linux with KDE 4.4.5.
After modifying my Xorg keymap to not emit XF86Wakeup if I hit the Fn key, the
 Fn-F4 shortcut for XF86Sleep started working using the script from post #17.
Of course this is not a true fix as this seems to bypass KDE.
Comment 21 Oliver Henshaw 2010-10-06 17:03:58 UTC
Can button events be duplicated in HAL and evdev? http://blogs.gnome.org/hughsie/2009/01/28/gnome-power-manager-and-buttons/ suggest so. Then this would be hard to fix with the hal backend. In which case the hotkey mapping in comment #17 would only work for users who have this problem - it might cause problems for users with a Sleep button that already works through HAL.

IIRC upower does not expose button events, so powerdevil in KDE 4.6 will have to listen to evdev for power button events. In which case it'll get keyboard events for free, right?
Comment 22 Dario Freddi 2010-11-10 00:37:27 UTC
*** Bug 182538 has been marked as a duplicate of this bug. ***
Comment 23 Dario Freddi 2010-11-10 00:37:56 UTC
*** Bug 245032 has been marked as a duplicate of this bug. ***
Comment 24 Dario Freddi 2010-11-10 00:43:13 UTC
*** Bug 245463 has been marked as a duplicate of this bug. ***
Comment 25 Dario Freddi 2010-11-10 01:08:12 UTC
*** Bug 247018 has been marked as a duplicate of this bug. ***
Comment 26 Ralf Jung 2010-11-10 08:49:58 UTC
Why has the bug by me (Bug 245463) been marked as duplicate of this? It was about the "change screen brightness" keys, and they did trigger some reaction (showing the current scren brightness), but did not change anything.
Comment 27 Dario Freddi 2010-11-10 10:59:17 UTC
Because all of these bugs are about handling some special keys by the Power Management System, hence they are fixable in a single run (and I'm about to commit a patch for this)
Comment 28 Dario Freddi 2010-11-10 11:01:24 UTC
SVN commit 1195058 by dafre:

BUG: 181444

Have the daemon react on Hibernate and Sleep buttons as provided from Qt input method

 M  +0 -7      actions/bundled/handlebuttonevents.cpp  
 M  +0 -1      actions/bundled/handlebuttonevents.h  
 M  +1 -6      actions/bundled/handlebuttoneventsconfig.cpp  
 M  +0 -1      actions/bundled/handlebuttoneventsconfig.h  
 M  +14 -0     powerdevilcore.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1195058
Comment 29 Robin Bankhead 2011-02-18 02:10:08 UTC
I have an issue similar to (Bug 245463) in kde-4.6.0 on Gentoo.  The Brightness Up/Down keys on my Samsung NC10 (Intel 945GME graphics) did not work at all prior to this release, but now both are detected correctly by KDED (as shown in System Settings > Global Keyboard Shortcuts) but only the "down" action has any effect (raising the OSD, changing the brightness), "up" does nothing.  This is regardless of what shortcut is assigned to the function.
Comment 30 Oliver Henshaw 2011-02-19 12:58:02 UTC
(In reply to comment #29)
> I have an issue similar to (Bug 245463) in kde-4.6.0 on Gentoo.  The Brightness
> Up/Down keys on my Samsung NC10 (Intel 945GME graphics) did not work at all
> prior to this release, but now both are detected correctly by KDED (as shown in
> System Settings > Global Keyboard Shortcuts) but only the "down" action has any
> effect (raising the OSD, changing the brightness), "up" does nothing.  This is
> regardless of what shortcut is assigned to the function.

Could this be bug #264534?
Comment 31 Robin Bankhead 2011-02-19 13:22:44 UTC
It could be, though it has some different symptoms: in bug #264534 increasing brightness does work from some initial values, whereas I haven't found such a case; and from the description I don't see why that bug would only affect increasing and not dimming.

Nevertheless, I'll ask there and see what those who fixed it have to say. Thanks.