After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 581363 - gnome-power-manager does not recognize suspend or power button
gnome-power-manager does not recognize suspend or power button
Status: RESOLVED NOTGNOME
Product: gnome-power-manager
Classification: Deprecated
Component: gnome-power-manager
2.26.x
Other All
: Normal major
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-05-04 19:48 UTC by Phil
Modified: 2009-06-26 07:42 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26



Description Phil 2009-05-04 19:48:26 UTC
Please describe the problem:
my suspend and power buttons are not working since --disable-legacy-buttons

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?
yes...aahm nothing happens every time

Other information:
first i merged it with --disable-legacy-buttons
because in 2.27 this option will be gone

gnome-power-manager --verbose tells me nothing if suspend or power button
hal detects /dev/input/event0 (Power Button)
and /dev/input/event4 (Suspend Button)
and many more =P

xev says nothing on pressing buttons
with --enable-legacy-buttons its working
I've installed Devicekit-power from git but it does not help

System Information:

hal-0.5.12-rc1
xorg-server-1.6.1
devicekit-003
devicekit-power(newest from git)
xf86-input-evdev-2.2.1
acpid-1.0.6

I have no PolicyKit support installed
In Gentoo i have -policykit USE-Flag set

in /var/log/messages acpid tells me buttons were pressed and a script has been run on /etc.../default.sh from gentoo

stop acpid does not help
in which way xorg tells gnome-power-manager the button is pressed if its not hal
I thought it was devicekit-power
Comment 1 Martin Pitt 2009-06-25 06:37:16 UTC
I had a look at this problem. It seems that the kernel side is alright, I get KEY_POWER input events:

$ sudo input-events 1
/dev/input/event1
   bustype : BUS_HOST
   vendor : 0x0
   product : 0x1
   version : 0
   name : "Power Button"
   phys : "PNP0C0C/button/input0"
   bits ev : EV_SYN EV_KEY

waiting for events
11:17:05.881107: EV_KEY KEY_POWER (0x74) pressed

However, they never make it through X.org, with xev I don't get XF86XK_PowerOff. g-p-m doesn't directly listen to input events, just to X.org key presses. So am I right in assuming that we need to fix the xorg driver to propagate KEY_POWER -> XF86XK_PowerOff, or is it meant to work in a different way?

We have the very same problem with the lid. While that generates an input event nowadays, that isn't converted to an X.org event again, so dk-p currently has to jump through some hoops to convert that. Should a similar trick be used for the power button? Should g-p-m listen to input event devices directly?
Comment 2 Martin Pitt 2009-06-25 06:39:05 UTC
Bumping severity, since getting rid of hal is one of the GNOME 2.28/3.0 goals, and this is a regression.
Comment 3 Martin Pitt 2009-06-26 07:42:10 UTC
Ah, it's because hal doesn't mark the power (and similar) buttons for x11_input.

I was about to add a rule to 10-x11-input.fdi to it when I discovered that this is more elegantly solved with an apparently unforwarded patch in Fedora:

  http://cvs.fedoraproject.org/viewvc/devel/hal/hal-add-keys-to-buttons.patch?revision=1.1&view=markup

I committed it to hal trunk now:

  http://cgit.freedesktop.org/hal/commit/?id=337ca70b39ce9477a01b97e990ad731ca13ad664