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

Bug #289322 reported by lopthopman on 2008-10-26
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-power-manager (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: gnome-power-manager

Currently, gnome-power-manager uses mouse and keyboard inactivity to determine idleness. As a second step, it then uses cpu load as an additional measure. So the computer is not considered idle unless the mouse, keyboard, and cpu are all idle. This definition is found in the gnome-power-manager manual for both Gutsy and Hardy.

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.

For display purposes, the computer can be considered idle when the user it not actively typing or mousing. This is the usual expected behavior. When I kick off a large compile and go off to lunch, it is annoying to return and find my backlight still at full brightness with no audience. It wastes power and longevity of the backlight.

I propose that there should be two different algorithms for idleness. One for suspend/hibernate that uses cpu load, and another for display blanking that does not consider cpu load.

DaveAbrahams (boostpro) wrote :

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

Pedro Villavicencio (pedro) 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.

Changed in gnome-power-manager (Ubuntu):
status: New → Incomplete

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.

Changed in gnome-power-manager (Ubuntu):
importance: Undecided → Wishlist
status: Incomplete → Confirmed

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.

Changed in gnome-power-manager (Ubuntu):
importance: Wishlist → Undecided
status: Confirmed → Incomplete
Flávio Etrusco (etrusco) wrote :

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

Flávio Etrusco (etrusco) wrote :

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)

Flávio Etrusco (etrusco) wrote :

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

Flávio Etrusco (etrusco) wrote :

(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.

Chris Coulson (chrisccoulson) wrote :

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

Changed in gnome-power-manager (Ubuntu):
status: Incomplete → Fix Released
Flávio Etrusco (etrusco) wrote :

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.

Flávio Etrusco (etrusco) wrote :

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.

Changed in gnome-power-manager (Ubuntu):
status: Fix Released → Confirmed

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.

summary: - gnome-power-manager needs different idleness definition for turning off
- display
+ gnome-power-manager put display to sleep timer incorrect when CPU is
+ being used
Changed in gnome-power-manager (Ubuntu):
importance: Undecided → Medium

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.

Changed in gnome-power-manager (Ubuntu):
status: Confirmed → Incomplete
Chris Coulson (chrisccoulson) wrote :

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

Changed in gnome-power-manager (Ubuntu):
status: Incomplete → Fix Released
importance: Medium → Wishlist
Flávio Etrusco (etrusco) wrote :

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).

Flávio Etrusco (etrusco) wrote :

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.

Chris Coulson (chrisccoulson) wrote :

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

Flávio Etrusco (etrusco) wrote :

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

Flávio Etrusco (etrusco) wrote :

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?

Chris Coulson (chrisccoulson) wrote :

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

lopthopman (lopthopman-ann0) wrote :

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....

Chris Coulson (chrisccoulson) wrote :

Well, the help is wrong then

Flávio Etrusco (etrusco) wrote :

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?

Chris Coulson (chrisccoulson) wrote :

I said that CPU usage is used during suspend

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers