gnome-power-manager put display to sleep timer incorrect when CPU is being used

I think the problems are way deeper than lack of intuitiveness. Most or all of the problems described in http://www.shallowsky.com/linux/x-screen-blanking.html seem to still be present in Intrepid.
Fundamentally, if there's a bug, it's that the g-p-m "put display to sleep" controls give the impression that they can be used to save power, but they just don't do anything. I'm filing a new bug on that issue and will reference it in a follow-up

https://bugs.launchpad.net/gnome-screensaver/+bug/308815

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Could you try to reproduce the same with Ubuntu 9.04? Thanks in advance.

On Apr 29, 2009, at 10:26 AM, Pedro Villavicencio wrote:

> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. You reported this bug a while ago and there hasn't been
> any activity in it recently. We were wondering is this still an issue
> for you? Could you try to reproduce the same with Ubuntu 9.04?
> Thanks in
> advance.

You tell me. It's not a symptom but a complaint about the
documentation. Do the docs for g-p-m now give a precise definition of
"idle?"

--
David Abrahams
BoostPro Computing
http://boostpro.com

This bug report is being marked Wishlist, as it not really a bug as such, but more of an idea to implement/change a feature/working of Ubuntu. Thank you.

Actually, I don't believe this is an issue any longer. Would you be able to see if this affects you in Lucid with a Live CD, as I have tested this and it seems ok. Thank you.

It's hard to confirm/debug this issue because timeout isn't respected most of the time.

Ok, a simple experiment doesn't seem to confirm this bug "exactly".
1) I set up the "put display to sleep when inactive" to 1 minute.
2) Leave the desktop idle with the programs (I'm using) open (firefox, pidgin, hgtk, gnome-terminal, etc): it takes 3:34min to turn off display.
3) Leave a cpu-intensive task running ("make clean; make" a project) and repeat step 2: it takes 3:47min to turn off display. (task took about 1:30min to complete)

BTW, the screensaver timeout is precise. In exactly 1min the screen starts to fade out.

(sorry for the spam)
It seems the display is never turned of if there's a window with "urgency" state! (blinking on the taskbar)
Screensaver kicks in normally.

Would you say that this was fixed, it's a little hard to understand. Can anyone confirm if this is still an issue in Lucid, as I am not seeing this behaviour. Thank you.

This is fixed, and has been for some time. For dimming the screen, it uses purely IDLETIME (which comes from the X server and resets on mouse/keyboard events). For blanking the screen, it uses an internal timer which starts when the screen dims, and will blank the screen after a period elapses without any keyboard or mouse movements.

For suspend, an internal timer is registered only when there is no keyboard or mouse movements AND the session is idle AND there are no suspend inhibits. When this timer expires, the machine will suspend if the CPU is not busy

Everything I reported is against Lucid, fully updated at the time of the report.
Chris: can you please clear the terminology on "dimming the screen" and "blanking the screen"? BTW I still see the problem of the notebook LCD un-dimming/backlight going back on for no reason.

Simple test:
1) Unplugged external keyboard and mouse to avoid interference.
2) Set "Put display to sleep when inactive for:" to 1min.
3) Time for display to go off with some applications open: 2:34min.
4) Time for display to go off with all applications closed: 1:12min.
So, the CPU or something related is clearly involved.

Dimming the screen turns the backlight down, and blanking turns the screen off, which happens a set time after the screen has been dimmed.

I think I understand what you mean in that: Although the "put display to sleep after" is set to 1 min, even without keyboard or mouse activity it takes a minute or 2 longer.

I think the problem seems to lie in the fact that the blanking timer counts AFTER the screen dims, which doesn't seem correct if the settings say "Put display to sleep when inactive for:", so I see what you mean. Will ask around on this one as it is a little puzzling.

Flavio, can you run "apport-collect 289322" and allow it to 'Change anything' so we can have the debugging information for g-p-m please? Thank you.

What applications are open. If applications create idle inhibitors, then this will affect the time the display takes to go to sleep, that is intentional.

Also, the 1 minute is on top of the time taken for the display to dim. The time to dim is variable (again, this is intentional), so that if you wiggle your mouse as soon as the display dims, gnome-power-manager automatically increases the dim time so that it doesn't keep pestering you.

The original bug report was specifically about not using CPU load for display dimming / blanking, which is already fixed. Please don't hijack and reopen bugs that are already fixed

The original poster says:

(...)
> As a second step, it then uses cpu load as an additional measure.
(...)
> This is great for determining when to suspend or hibernate. But it is
> counter intuitive for turning off the display. There are a large number
> of bugs filed againt g-p-m for display blanking issues: not working at
> all, intermittent failure, other stuff. I believe it is because of the cpu
> criteria that no one is expecting.
(...)

AFAICS this is exactly the bug I'm proving.
However I'm confusing the terminology myself. When I said "dimming", I meant that the display was completely off, and actually seemingly with DPMS and not just with backlight off. BTW dimming seems to be working perfectly BTW (not affected by CPU).

Teej, do you mean you can't reproduce the bug?
Chris, you want to set status Wontfix, then OK, it's your decision and you're a Canonical dev, but this is not Fixed.

Well, the issue you're describing isn't the same as the original reporter. CPU usage does not influence the timing of display blanking in gnome-power-manager (you can check that for yourself in src/gpm-idle.c). If CPU usage *is* influencing the timing in some way, then that's a bug in some other component rather than gnome-power-manager.

The 1 minute you set corresponds to the time period between the display dimming, and then switching off (blanking). Is that what you are measuring? If not, then I already said that the dimming time is deliberately variable. The idle dim time will double (from the default 10 seconds) each time you cause a keyboard or mouse event within 10 seconds of going idle

I'm measuring with AC plugged on, so there's no dimming.

OMG. It's been sometime since I tested running on battery. Now unplugging from AC doesn't "reduce backlight brightness", and the display doesn't dim after 1min+...
Does g-p-m count dimming even on AC? Maybe this is the problem? And maybe CPU detection is too sensible (mine shows 4% in use)? Is disk access accounted for?

The time period is still there. Try doing it without AC

Chris, gpm does use cpu as a criteria, and is documented as doing so:

gpm help:
When the timeout set in gnome-power-preferences is reached,
and the CPU load is idle, then the idle action is performed, which is usually to turn off the screen, or to suspend or hibernate.
^^^^^^^^^^^^^^^^^^^^^^^^^^

So if it is not in idle.c, it is in some other .c file....

Well, the help is wrong then

Wait. Didn't you, Chris, said that CPU use is taken into account when dimming? Isn't this bug requesting/arguing that blank timeout should be fixed i.e. should not take CPU use into consideration? So should the dim timeout be taken out of the equation for blank timeout?

I said that CPU usage is used during suspend