[Desktop-packages] [Bug 269951] Re: XF86Standby does not trigger hibernate or sleep
The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305562 ** No longer affects: somerville -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-power-manager in Ubuntu. https://bugs.launchpad.net/bugs/269951 Title: XF86Standby does not trigger hibernate or sleep Status in “gnome-power-manager” package in Ubuntu: Invalid Status in “gnome-power-manager” source package in Intrepid: Fix Released Bug description: IMPACT: On an Inspiron 1420 (and possibly other Dell models), the Standby key (Fn+F1 in my case, with a little half-moon on it) does not trigger a standby action (Hibernate or Sleep). Both hibernate and sleep actions *can* be triggered from the battery icon, and will properly suspend and resume. Running xev, the key is detected and forwarded up to Gnome by X, so I believe X is doing whatever it's supposed to do. The output from xev is: KeyPress event, serial 33, synthetic NO, window 0x381, root 0x7b, subw 0x0, time 7902503, (870,331), root:(876,404), state 0x4, keycode 213 (keysym 0x1008ff10, XF86Standby), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False I can also hook XF86Standby to other Gnome actions, like launching the help browser, using gnome-keybinding-properties, and it successfully launches the help browser. So the key events are getting handled and propagated. However, from what I understand, hooking the key to Suspend in gnome-keybinding-properties is an obsolete way for setting this up. Regardless, it doesn't work anyway; the event seems to get lost somewhere in gdm and never runs the /usr/sbin/pm-suspend command that it seems to be configured to trigger. Running that command from the console does work at triggering sleep though. ADDRESSING: This bug has been addressed via a one-line patch to gnome-power- manager. Jaunty is unaffected because HAL send XF86Standby as dbus event. TEST CASE: To reproduce this bug, try pressing the key that corresponds to XF86Standby. REGRESSION POTENTIAL: There is no regression potential. This patch simply enables a hotkey that was disabled (and mislabeled) previously. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/269951/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 269951] Re: XF86Standby does not trigger hibernate or sleep
** Changed in: somerville Status: New = Fix Released ** No longer affects: dell -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-power-manager in Ubuntu. https://bugs.launchpad.net/bugs/269951 Title: XF86Standby does not trigger hibernate or sleep Status in The Somerville Project: Fix Released Status in “gnome-power-manager” package in Ubuntu: Invalid Status in “gnome-power-manager” source package in Intrepid: Fix Released Bug description: IMPACT: On an Inspiron 1420 (and possibly other Dell models), the Standby key (Fn+F1 in my case, with a little half-moon on it) does not trigger a standby action (Hibernate or Sleep). Both hibernate and sleep actions *can* be triggered from the battery icon, and will properly suspend and resume. Running xev, the key is detected and forwarded up to Gnome by X, so I believe X is doing whatever it's supposed to do. The output from xev is: KeyPress event, serial 33, synthetic NO, window 0x381, root 0x7b, subw 0x0, time 7902503, (870,331), root:(876,404), state 0x4, keycode 213 (keysym 0x1008ff10, XF86Standby), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False I can also hook XF86Standby to other Gnome actions, like launching the help browser, using gnome-keybinding-properties, and it successfully launches the help browser. So the key events are getting handled and propagated. However, from what I understand, hooking the key to Suspend in gnome-keybinding-properties is an obsolete way for setting this up. Regardless, it doesn't work anyway; the event seems to get lost somewhere in gdm and never runs the /usr/sbin/pm-suspend command that it seems to be configured to trigger. Running that command from the console does work at triggering sleep though. ADDRESSING: This bug has been addressed via a one-line patch to gnome-power- manager. Jaunty is unaffected because HAL send XF86Standby as dbus event. TEST CASE: To reproduce this bug, try pressing the key that corresponds to XF86Standby. REGRESSION POTENTIAL: There is no regression potential. This patch simply enables a hotkey that was disabled (and mislabeled) previously. To manage notifications about this bug go to: https://bugs.launchpad.net/somerville/+bug/269951/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
