GNOME Power Manager unstableness

Recently there has been a period of where gnome-power-manager wasn’t quite as stable and bug free as I would like. The reasons basically boil down to:

  • Rewriting the engine to support DeviceKit-power rather than HAL
  • Switching to using xbacklight rather than HAL to change the backlight (but falling back to HAL if xbacklight is not available)
  • Rewriting the idle interactions to not rely on gnome-screensaver, but instead using gnome-session and X idletime
  • Supporting HAL buttons and X buttons, and trying to filter out the duplicates
  • Working around the fact that switching the monitor off using DPMS resets the IDLETIME…. urgh.
  • Switching to using DeviceKit-power to do the suspend and hibernate, instead of using HAL

So, for the last few months I’ve been essentially trying to do the software equivalent of underpinning a house. I’ve spent the last couple of days adding more self check code, and fixing up the bugs that the new tests have found. Specifically, if your machine randomly switched off your display when you’re working, or when switching sessions didn’t restore your brightness correctly then git master probably might work for you.

Could people that have had problems, please try git master and give me success/failure as comments to the blog comment please. If the idletime and dimming stuff is 100% fixed now, then I’ll backport the fixes to stable and do a new release. Thanks.

p.s. If you change the value of GPM_USE_COMPOSITE in src/gpm-engine.c to 1 and recompile, then multiple batteries might work correctly too. Untested (still waiting for my ultra-bay battery to be delivered), so no promises.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

19 thoughts on “GNOME Power Manager unstableness”

  1. The only problem with 2.26.1 I experience is that I want to have set “Put display to sleep when inactive for” to (for example 1 hour), but when I lock the screen (I don’t use screensaver themes, just a black screen) I want to see the monitor switched off using DPMS immediately, which does not happen. I have to set the above setting to the lowest value (11 minutes) everytime before I want to lock the screen as a workaround.

  3. I have a question: does every software needs to change the way they keep the session alive to support the new g-p-m? when I play a film in totem my screen goes black after the minutes I set up in g-p-m, and this should not happen

  5. Where these changes necessary to land in 2.26? Couldn’t you have waited till they were major enough, like other projects do? I’m sorry to be harsh, but the 2.26 series is totally fucked up! This whole change to DeviceKit-power should have happened slower, like in 2.25 + 2.27 or so. You released a totally buggy software in a branch that’s supposed to be “stable” (whatever that means)…

  7. Richard:

    It seems current g-p-m git master depends on devkit-power git master but it does not check it in configure stage. The offending bit seems to be dkp_client_lid_is_closed().

  9. Pingback: New hedge funds: smaller and thriftier | Bad Credit NOT!
  12. Pingback: Blog Comments | SEO Blog

  13. Adam:

    I’ve got it to work just after posting the first comment. I’ve tried to post the the links two commits to devkit-power that are enough to make g-p-m fully build and work but it seems the spam filter ate them.

    Richard:

    I can confirm git master fixed the blackouts for me. Feel free to mail me if you need any harware info.

  14. I don’t know if it’s useful information to you since you’ve probably figured this out by now, but if you look at the source for the xprintidle command, you’ll find their workaround for the DPMS bug. I’ve also written a python extension to get the correct idle time using that code if you’re interested.

    _J

  15. @James, thanks for that — the bug is in the xserver and we currently work around it in gnome-power-manager by setting a very small idletime alarm after a dpms state change. Hopefully it can be fixed in the X server without too many problems.

  16. @Michael: We did merge DeviceKit-power support in 2-25. And a lot of those changes happened only in 2-27, not stable branches,

  17. Richard – I take it you’ve seen the several responses on the fedora-test-list thread and in the bug report saying the git build I did hasn’t fixed the problem for them?

Comments are closed.