Category: gnome-power-manager

Okay, after having F11 g-p-m blank the screen on me whilst watching some short videos in totem yesterday, I got really angry. It seems lots of other people feel the same way.

I’ve audited all the IDLETIME code in gnome-power-manager multiple times, and when I’ve run it in a console and watched the output, it all seems to work 100% okay for days on end, and then fails when you’re actually trying to do something. And then I had an epiphany: It only seems to fall over gnome-session is involved with handling inhibits.

So, this works:

GPMIDLEDEBUG=1 ./gnome-power-manager

…wait 10 seconds…

IDLETIME fires the idle alarm expired (and g-p-m dims the screen) and the reset alarm is setup

…move the mouse…

IDLETIME fires the reset alarm expired

Then I issue an inhibit request to org.gnome.SessionManager with parameters (‘test-program’,0,’testing’,8) using d-feet and get back a cookie like normal. Session becomes inhibited.

…wait 10 seconds…

IDLETIME fires the idle alarm expired (but g-p-m doesn’t dim the screen, as the session is inhibited from totem) and the reset alarm is setup

…move the mouse…

NOTHING. No event from X.

…close d-feet…

The inhibit gets auto-revoked, session becomes non-inhibited, and g-p-m assumes that x has been idle for a long time, and also the session is not inhibited, and so switches off the screen. You can see this when using GPMIDLEDEBUG as the second icon is a box, not a computer icon.

Now g-p-m is confused, and has to be restarted before it will reset the new idletime counter. You can’t reproduce with the original idlecounter-demo program when using XNextEvent, but you can as soon as you hook into gdk with gdk_window_add_filter. It really looks like something is doing GDK_FILTER_REMOVE on the reset alarm at some point. There’s a test program here which you can see the bug without gnome-power-manager running, just to prove it’s not a silly bug or race in gnome-power-manager. It could also be an X bug, as the XSync stuff isn’t that widely used, although all gnome-session is doing is XSyncDestroyAlarm’ing an alarm, which shouldn’t affect gnome-power-manager’s alarms at all.

After looking in the forums, this problem looks like it’s triggered lots, and by many different users. I would appreciate any help here as I’m well and truly stuck. Thanks.

Richard.

p.s. if anyone knows how to debug gnome-session to see the debug output, I would be very grateful. Any attempts at replacing gnome-session process in my session lead me to a forced logout.

gnome-power-manager shows a GtkStatusIcon of the battery state. When gnome-power-manager is launched from gnome-session at login time, the icon is not shown on the panel, even though the icon name is set and it’s set visible. It isn’t shown even doing by setting the filename icon again and doing gtk_status_icon_set_visible() several seconds after starting. gtk_status_icon_is_embedded() is always false.

If I do “killall gnome-power-manager”, gnome-session respawns the binary (because of X-GNOME-AutoRestart) and the icon shows correctly. It also starts correctly if you launch it manually from gnome-terminal.

Even if I remove the X-GNOME-Autostart-Phase=Panel (so that it starts as an application, well after the panel is formed) it still doesn’t show.

If you’ve got any tips on how to debug this I would appreciate it. I’m out of ideas. Thanks.

Another change coming in 2-27 – gnome-power-manager will stop listening to HAL for button events. Peter has been rocking with evdev over the last few months and now all the multimedia buttons come up through both X and HAL. g-p-m has to filter the second button, and mostly this works well. Some distros are still not configuring evdev properly, and some still inject events into HAL, or rely on HAL to scrape events from oddball kernel interfaces. The way forward is using INPUT in the kernel, and the vast majority of events are now coming through INPUT from random devices, and through X to applications.

Once upon a time there were three inhibit API’s:

• HAL: system-wide locks on suspend, hibernate and shutdown
• gnome-power-manager: session inhibit for idle suspend and hibernate
• gnome-screensaver: session inhibit for screen blanking and DPMS

Obviously, this has a few big flaws:

• An application might have to inhibit three services, using slightly different methods
• gnome-screensaver has to expose lots of low level icky stuff for g-p-m to consume
• We’ve got a screensaver doing idle detection
• We’ve got gnome-power-manager writing into gnome-screensaver GConf keys to get the timeouts correct
• It’s not possible to prevent logout or user switching
• The hand-off between the session and power manager is poorly defined, so we get stupid libnotify popups rather than nice dialogue integration.
• We don’t integrate with presence services, so we just ignore away/busy/idle status.

Basically, we need the session manager to take care of the all registrations and handle the interactions. Luckily, this is what Jon McCann has done in gnome-session.

These new interfaces are session management done right. Of course, this breaks the old world order of inhibiting gnome-power-manager and gnome-screensaver. For the 2-26 series all inhibits are proxied by g-p-m and g-s to gnome-session, so everything should pretty much just work like before. But, early in the 2-27 cycle we’re going to remove this compat code and everything will have to go through gnome-session. For most code it’ll just be a couple of lines changed and behind the scenes it’s a much simpler and more powerful design.

Like some of the other changes we are making at the moment (DeviceKit, PulseAudio, KMS) this is a new way of doing things, and things might temporarily break. They’ll be regressions, but things can be fixed quickly and most importantly, correctly. What we were using before just wasn’t good enough. With this new framework, we can do it right for GNOME 3.0.