| 2008-09-13 21:25:27 |
Bryce Harrington |
bug |
|
|
added bug |
| 2008-09-13 22:50:24 |
Bryce Harrington |
bug |
|
|
added attachment 'dmesg-before.txt' (dmesg) |
| 2008-09-13 22:50:56 |
Bryce Harrington |
bug |
|
|
added attachment 'lspci-vvnn.txt' (lspci-vvnn.txt) |
| 2008-09-13 22:51:42 |
Bryce Harrington |
bug |
|
|
added attachment 'gnome-power-bugreport-before.txt' (gnome-power-bugreport) |
| 2008-09-13 22:54:14 |
Bryce Harrington |
bug |
|
|
added attachment 'Xorg.0.log' (Xorg.0.log) |
| 2008-09-14 18:29:39 |
Martin Pitt |
linux: status |
New |
Confirmed |
|
| 2008-09-14 18:29:39 |
Martin Pitt |
linux: statusexplanation |
|
The same happens on my Latitude D430 (which also worked fine under Hardy).
Bryce, /proc/acpi/event is busy because acpid is already connected to it. Stop it, then you can cat it:
$ sudo /etc/init.d/acpid stop
* Stopping ACPI services... [ OK ]
$ sudo cat /proc/acpi/event
button/power PBTN 00000080 00000001
If I press Fn+F1 (hibernate) or Fn+F3 (battery status), nothing happens. If I press the power button, I get the output above. |
|
| 2008-09-17 00:58:07 |
Bryce Harrington |
linux: bugtargetdisplayname |
linux (Ubuntu) |
acpi-support (Ubuntu) |
|
| 2008-09-17 00:58:07 |
Bryce Harrington |
linux: bugtargetname |
linux (Ubuntu) |
acpi-support (Ubuntu) |
|
| 2008-09-17 00:58:07 |
Bryce Harrington |
linux: statusexplanation |
The same happens on my Latitude D430 (which also worked fine under Hardy).
Bryce, /proc/acpi/event is busy because acpid is already connected to it. Stop it, then you can cat it:
$ sudo /etc/init.d/acpid stop
* Stopping ACPI services... [ OK ]
$ sudo cat /proc/acpi/event
button/power PBTN 00000080 00000001
If I press Fn+F1 (hibernate) or Fn+F3 (battery status), nothing happens. If I press the power button, I get the output above. |
[Looks like there are many similar reported issues in acpi-support, so guessing it belongs there rather than in the kernel.] |
|
| 2008-09-17 00:58:07 |
Bryce Harrington |
linux: title |
Bug #269951 in linux (Ubuntu): "Fn+F1 (XF86Standby) on Inspiron 1420 does not trigger hibernate or sleep" |
Bug #269951 in acpi-support (Ubuntu): "Fn+F1 (XF86Standby) on Inspiron 1420 does not trigger hibernate or sleep" |
|
| 2008-10-04 11:51:59 |
Harvey Muller |
bug |
|
|
assigned to dell |
| 2009-01-09 19:35:33 |
Mario Limonciello |
acpi-support: bugtargetdisplayname |
acpi-support (Ubuntu) |
gnome-power-manager (Ubuntu) |
|
| 2009-01-09 19:35:33 |
Mario Limonciello |
acpi-support: bugtargetname |
acpi-support (Ubuntu) |
gnome-power-manager (Ubuntu) |
|
| 2009-01-09 19:35:33 |
Mario Limonciello |
acpi-support: statusexplanation |
[Looks like there are many similar reported issues in acpi-support, so guessing it belongs there rather than in the kernel.] |
|
|
| 2009-01-09 19:35:33 |
Mario Limonciello |
acpi-support: title |
Bug #269951 in acpi-support (Ubuntu): "Fn+F1 (XF86Standby) on Inspiron 1420 does not trigger hibernate or sleep" |
Bug #269951 in gnome-power-manager (Ubuntu): "Fn+F1 (XF86Standby) on Inspiron 1420 does not trigger hibernate or sleep" |
|
| 2009-01-09 19:39:24 |
Mario Limonciello |
description |
[Splitting this out from bug 267682]
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). From what I gather, it is supposed to trigger hibernate.
Both hibernate and sleep actions *can* be triggered from the battery icon, and will properly suspend and resume (although networking is lost on resume from sleep, but that's a separate issue).
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 0x3800001,
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.
I don't know if this is relevant, but I've tried viewing the contents of /proc/acpi/events, however it doesn't let me read it as I think it should:
~$ sudo cat /proc/acpi/event
[sudo] password for bryce:
cat: /proc/acpi/event: Device or resource busy
I'm not certain whether this is a kernel bug, acpi bug, hal, X, or...? Near as I can tell it's not X, but who knows. |
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 0x3800001,
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. |
|
| 2009-01-09 19:39:24 |
Mario Limonciello |
title |
Fn+F1 (XF86Standby) on Inspiron 1420 does not trigger hibernate or sleep |
XF86Standby does not trigger hibernate or sleep |
|
| 2009-01-09 19:39:44 |
Mario Limonciello |
dell: status |
New |
Fix Committed |
|
| 2009-01-09 19:39:44 |
Mario Limonciello |
dell: statusexplanation |
|
|
|
| 2009-01-09 19:40:20 |
Mario Limonciello |
gnome-power-manager: status |
Confirmed |
Invalid |
|
| 2009-01-09 19:41:19 |
Mario Limonciello |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2009-01-20 09:00:18 |
Martin Pitt |
gnome-power-manager: status |
New |
Fix Committed |
|
| 2009-01-20 09:00:18 |
Martin Pitt |
gnome-power-manager: statusexplanation |
|
|
|
| 2009-01-20 09:00:45 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2009-01-27 17:19:59 |
Mario Limonciello |
dell: status |
Fix Committed |
Fix Released |
|
| 2009-01-28 00:35:11 |
Launchpad Janitor |
gnome-power-manager: status |
Fix Committed |
Fix Released |
|
| 2010-02-21 06:38:25 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/intrepid-proposed/gnome-power-manager |
|
| 2014-04-10 04:11:43 |
Timothy R. Chavez |
somerville: status |
New |
Fix Released |
|
| 2014-04-10 04:11:47 |
Timothy R. Chavez |
bug task deleted |
dell |
|
|
| 2014-04-10 08:29:32 |
Timothy R. Chavez |
bug task deleted |
somerville |
|
|
