gnome-power-manager and blanking (removal of bodges)

I’ve been working with the xorg people upstream, trying to sort out all the remaining blanking problems properly, rather than just working around the problem. I’ll explain the key issues:

gnome-power-manager uses a counter inside Xorg called IDLETIME. This counter is incremented only when the user does not move the mouse, or click some keys. When the user clicks something, the IDLECOUNTER is reset. Unfortunately, the IDLETIME counter was also being reset (in two places!) when the DPMS level is set. Now, this doesn’t affect most users of IDLETIME, as the screen doesn’t blank that often. For the most part, IDLETIME was a welcome addition to the X server.

For gnome-power-manager, we set up a XSync alarm for IDLE counter being over a certain value, and then we set up a XSync alarm for the IDLE counter being reset. When the alarm goes off we wait the policy time for the “display sleep” and then turn off the panel using DPMS. Which then resets the idletime, which turns the panel back on. Urgh.

So, what we do is handle the reset event, and if the event is less than a few milliseconds since we did a DPMS action, we ignore the alarm. Of course, if we ignore the alarm, then we don’t get the reset event when the user moves the mouse and the IDLECOUNTER gets reset. So, in this case, gnome-power-manager sets up a 1ms timeout when we detect an alarm a small time since a DPMS event. This triggers almost immediately, and so we get the alarm fired practically straight away.

Except, due to another X bug, if we set an alarm value on the timer that’s already been passed, we don’t get the alarm fired. So, if you’ve got a high load value, or a slow system, you could miss the alarm. So, we had to raise the bodge alarm value to 50ms, rather than 1ms. Urgh.

But then, there’s a nice 50ms race between the two timers, and 50ms is a small amount of time in human terms, right? No. When the user is reading something, and the display blanks, most users move the mouse pretty much straight away. If you hit this 50ms race (which some people seem able to do, me included) then gnome-power-manager misses the reset event, and if configured to do so, gnome-power-manager will still think your idle, and then go on to suspend your system. Urgh.

So, the only way to fix gnome-power-manager and remove all these ugly kludges would be to fix the xserver. I’ve sent two patches to xorg-devel which remove the IDLECOUNTER reset when DPMS off is sent. The second upstream patch is here.

So, I’ll remove the kludges from gnome-power-manager git master today and will depend on a runtime version of the xserver that has these patches applied. If you are trying to run gnome-power-manager with a broken version of X, gnome-power-manager will warn you in the notification area. Distributors will just need to patch xserver with my previous patch and the current one to have all the issues resolved with git master.

edit: updated with links to the signed off patches in xserver!

Published by


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.

18 thoughts on “gnome-power-manager and blanking (removal of bodges)”

  1. Well, I’d just like to say thank you for working so hard at making our laptop experiences so much more pleasurable.

    And sending patches to to fix the problem elegantly is even more appreciated.

    Thanks :)

  2. Sounds like there are a lot of bugs in X. :( While things are better compared to the XFree86 days I’m really wondering why such an important project like X receives so relatively little developer attention.

    1. A great question. It might have been productive to keep the number of core developers low in the transition period, but that is changing.

      xorg seems to have a much more scalable developer infrastructure and developing process as it is at the moment. Looks like it is room for a lot of developers without becoming a political mess.

      Would be great if the major distros could provide more developers.

  3. Thanks for the patches. The screen blanking which for me also meant random standby are gone and working on my notebook is fun again.

  4. Quick question, would this bug have anything to do with a recent idling problem in Ubuntu Karmic resulting in a/screensaver never starting and b/monitor never shutting?

  5. Hi. Just to let you know…
    I run Ubuntu Karmic Studio with the current real-time kernel.
    I have nvidia and installed the available closed-source driver (I think it was version 180) a week ago.
    The driver wouldn’t load, so I commented out driver =”nvidia” in xorg.conf and was able to reboot that way.
    Since then, I have had some truly wild blackouts, mostly using dragon naturally speaking running on wine. Now, to run DNS at all, (because wine won’t work with pulseaudio) I have killall’ed pulseaudio and installed esound.
    I’m thinking of trying the version 185 driver today.

  6. Thanks very much, Richard!

    As it happens, i’ve been been looking into the same issue – screen blanking not working properly – for the past couple hours.
    My conclusion is exactly the one you’re talking about – DPMSForceLevel seems to reset IDLETIME timer and cause it to fire about 260 ms later. here’s some debug output:

    TI:05:22:16 TH:0x85be168 FI:gpm-dpms.c FN:gpm_dpms_x11_set_mode,184
    – calling DPMSForceLevel
    TI:05:22:16 TH:0x85be168 FI:egg-idletime.c FN:egg_idletime_event_filter_cb,253
    – callback for alarm 0: 261 vs 9999

    problem is, that it’s happening even though i’m running Xorg server with the patch you suggested. i’m using Ubuntu Karmic and i’ve just confirmed that latest build of the server contains the patch:

    $ apt-get -b source xorg-server


    Applying patch 183_dont_reset_event_time.patch
    patching file dix/window.c
    Hunk #1 succeeded at 3169 (offset 41 lines).

    here’s output of X -version:

    $ sudo X -version

    X.Org X Server 1.6.3
    Release Date: 2009-7-31
    X Protocol Version 11, Revision 0
    Build Operating System: Linux 2.6.24-23-server i686 Ubuntu
    Current Operating System: Linux acer 2.6.31-10-generic #34-Ubuntu SMP Wed Sep 16 00:23:19 UTC 2009 i686
    Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.31-10-generic root=/dev/mapper/acer-root ro splash quiet
    Build Date: 08 September 2009 11:15:47PM
    xorg-server 2:1.6.3-1ubuntu6 (buildd@rothera.buildd)

    and yes, i’ve applied updates and rebooted just 4 hours ago, so this is the server that is running.
    any idea why am i still seeing the bug? any suggestions where to look / patches to try?

    1. Hi, like Sonja my screen blanked & when it snapped back on, I got the notification-icon in the top bar that included this URL and led me here. This is 11/19/09, so quite a while after you posted the patch and after Ubu 9.10 Karmic was officially released. I am using Karmic UNR on a Toshiba NB205 netbook. I am not a programmer; I am a social theorist. So, though I am willing to troubleshoot and very occasionally recompile a kernel with patches, I have no idea what to do with the code you have provided. Furthermore, given that I have been running Ubu 9.10 UNR for three weeks afrer official release, should’t this patch be built in? Does this indicate another, closely-related problem that triggered your alert-icon and directed me to this page?

  7. Thanks for the info, Richard! I got an error message in Ubuntu today (after my screen went black, randomly) stating: “Session active, not inhibited, screen idle. If you can see this text, your display server is broken and you should notify your distributor. Please see for more information.” The problem is, I don’t know how to apply your patches. Please help! Thank you!

  8. In F12 I see the gnome-power-manager message “Session active, not inhibited, screen idle. If you can see this text, your display server is broken and you should notify your distributor…. ” when running a gnome session under gnome. I’m not sure if this is a misfire of the gnome-power-manager moan, or that the tigervnc server has the same problem the xserver had before your patches?

    Reported here, against tigervnc:

  9. I have Karmic 9.10 on my netbook and my screen went blank, came back up, and I was introduced to this applet that had alt text to direct me here! After a few minutes, it has disappeared. I’ll wait to see if this comes up again.

  10. I just got the message running Ubuntu 9.10 to visit here about blanking issues. In my case I am using Cygwins on Windows XP to XDMCP into the box. The system should probably be able to detect when the display is coming from a virtual display and not worry about trying to blank or know how to blank in that specific scenerio.

  11. The message comes up when using tigervnc-server in Fedora. Display blanking isn’t very useful on a VNC-connected X anyway…

Comments are closed.