|Summary:||powerdevil should listen to XF86Sleep|
|Product:||[Frameworks and Libraries] solid||Reporter:||Armin Berres <armin>|
|Component:||powermanagement-daemon||Assignee:||Dario Freddi <drf>|
|Severity:||normal||CC:||arvidjaar, CaptainSifff, cddesjardins, chris.bainbridge, claudiomkd, dave.greengas, echidnaman, glua, null, olaf, oliver.henshaw, post, rdieter, robin.bankhead, toddrpartridge|
|Latest Commit:||Version Fixed In:|
|Attachments:||Global hotkey definition mapping the Sleep key to a org.freedesktop.PowerManagement.Suspend dbus call|
Description Armin Berres 2009-01-21 00:55:58 UTC
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.