g-p-m failing to use DPMS to power off display

Bug #34233 reported by Kasper Peeters
32
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-power-manager (Ubuntu)
Invalid
Medium
Unassigned
gnome-screensaver (Ubuntu)
Invalid
Medium
Oliver Grawert

Bug Description

Gnome-screensaver does not seem to have DPMS support,
leaving the monitor on unnecessarily.

Revision history for this message
Oliver Grawert (ogra) wrote :

power management is handled completely in gnome-power-manager, the dpms off settings are found in system->preferences->power management
(path might differ i have no english install around)
or in the preferences of the battery icon in the notification area in case you use a laptop

Changed in gnome-screensaver:
assignee: nobody → ogra
status: Unconfirmed → Rejected
Revision history for this message
Kasper Peeters (kasper-peeters) wrote :

In that case, I'd like to file a bug report: despite the fact that "put display to sleep when the computer is inactive for" is set to "30 minutes" (in both AC and battery mode), the display never switches off. It does work with xscreensaver.

Revision history for this message
Richard Hughes (richard-hughes) wrote :

Kasper, do you have gnome-power-manger *and* gnome-screensaver running when you did the test? You might want to look at the debugging output of g-s and g-p-m for any obvious errors.

Matt Zimmerman (mdz)
Changed in gnome-power-manager:
status: Unconfirmed → Needs Info
Revision history for this message
Matthew Buckett (buckett) wrote :

I am seeing the same bug and I don't have gnome-screensaver running. I have set the display to go to sleep after 1 minute but it never does. Looking at the xset values they are all at 0:

buckett@desktop:~$ xset q | grep -A3 ^DPMS
DPMS (Energy Star):
  Standby: 0 Suspend: 0 Off: 0
  DPMS is Enabled
  Monitor is On

Does gnome-power-manager set the values queried by xset?

Revision history for this message
Richard Hughes (richard-hughes) wrote :

You need to use gnome-screensaver as it declares the session idle and g-p-m is then able to set the dpms settings. See http://live.gnome.org/GnomePowerManager/Faq

Revision history for this message
Matthew Buckett (buckett) wrote :

If you need to have gnome-screensaver running shouldn't g-p-m check to see that it's running?

With gnome-screensaver running my monitor still doesn't enter standy although the screensaver now starts.

Revision history for this message
Richard Hughes (richard-hughes) wrote :

It does, if you look at the output of gnome-power-manager --no-daemon --verbose you''ll see a big fat warning. The reason you don't get a user clickable warning is that some distros start g-p-m then g-s, and so we would warn when there is not problem. Can you attach the output of gnome-power-manager --no-daemon --verbose please, thanks.

Revision history for this message
Johannes Hessellund (osos) wrote :

This problem still persist.

I have done a fresh dapper final install, and gnome-power-manager set dpms = 0 0 0 !

I actualle wont screensaver to be off, and blanking only using dpms. Is it posible?

I did set my screensaver on, which does work. How do I solve this DPMS issue?

Revision history for this message
Johannes Hessellund (osos) wrote : gpm --verbose

Here the output of gnome-power-manager.

It really seems to set timings to "0 0 0" !

By the way I am using a Thinkpad T42 with radeon 7500 gfx.

Revision history for this message
Kyle Peterson (kpeterson) wrote :

Same exact problem here:

#xset -q
DPMS (Energy Star):
  Standby: 0 Suspend: 0 Off: 0
  DPMS is Enabled
  Monitor is On

I'm using a Toshiba Satellite 3000 with nvidia geforce2go. Gnome-screen-saver is running.

Revision history for this message
drberg1000 (drberg1000) wrote :

I see this same issue with a Linux Certified LC2210D laptop. Gnome-screensaver is running dpms timeouts are all 0.

Manually setting the xset variables fixes the problem, but the settings are lost on sleep. What would be the appropriate place to have the command run as a temporary fix?

Revision history for this message
Johannes Hessellund (osos) wrote :

Are you using external monitors ?
Having laptop lid closed ?

Then this bug might be it:
http://bugzilla.gnome.org/show_bug.cgi?id=365016

Revision history for this message
drberg1000 (drberg1000) wrote : Re: [Bug 34233] Re: g-p-m failing to use DPMS to power off display

No external monitors.

cat /proc/acpi/button/lid/LID/state
always returns:
state: closed

but that I believe is a totally separate bug.

On 11/2/06, Johannes Hansen <email address hidden> wrote:
> Are you using external monitors ?
> Having laptop lid closed ?
>
> Then this bug might be it:
> http://bugzilla.gnome.org/show_bug.cgi?id=365016
>
> --
> g-p-m failing to use DPMS to power off display
> https://launchpad.net/bugs/34233
>

Revision history for this message
Johannes Hessellund (osos) wrote :

Yes it might be a seperate bug. And still they are connected.

As I tracked down, due to other bugfixes, g-p-m ignores g-s idle events when lid=closed !
Meaning if lid=closed you will never get a running screensaver nor will it ever dpms. Only if lid=open it will dpms !!!

I get the problem when using external monitor and closing my lid, with open lid everythings fine.

Solution proposed in the gnome-bug

Revision history for this message
drberg1000 (drberg1000) wrote :

On 11/2/06, Johannes Hansen <email address hidden> wrote:
> As I tracked down, due to other bugfixes, g-p-m ignores g-s idle events when lid=closed !
> Meaning if lid=closed you will never get a running screensaver nor will it ever dpms. Only if lid=open it will dpms !!!

However, I do still get screensaver and screen locking without a problem.

I'll check out the gnome-bug.

Is the lid closed bug another gnome-power-manager bug or should I
submit that to a different package?

Revision history for this message
Richard Hughes (richard-hughes) wrote :

>Meaning if lid=closed you will never get a running screensaver nor will it ever dpms.
>Only if lid=open it will dpms !!!

Incorrect. If the lid is closed then the automatic DPMS timeout is disabled, and the lid DPMS is forced off. When the lid id re-opened, then the DPMS is turned on, and the timeout restored. It sounds like you may be suffering from an ACPI problem (or a bios or hardware problem) where the lid status is not being detected correctly.

Richard.

Revision history for this message
drberg1000 (drberg1000) wrote :

On 11/2/06, Richard Hughes <email address hidden> wrote:
> >Meaning if lid=closed you will never get a running screensaver nor will it ever dpms.
> >Only if lid=open it will dpms !!!
>
> Incorrect. If the lid is closed then the automatic DPMS timeout is
> disabled, and the lid DPMS is forced off. When the lid id re-opened,
> then the DPMS is turned on, and the timeout restored. It sounds like you
> may be suffering from an ACPI problem (or a bios or hardware problem)
> where the lid status is not being detected correctly.

So if I read this correctly you think the lid state problem is (in my
case) causing this bug and to address the issue I should file the bug
with ACPI. Is that correct?

--Dave

Revision history for this message
pgf (pgf) wrote :

can someone comment on the state of this thread, particularly with respect to ubuntu dapper? i can't seem to get dpms to kick in, no matter what i do with gnome-screensaver or gnome-power-manager. what makes this thread interesting to me is that the configuration involves a laptop sitting closed on a desk, connected to an external keyboard/monitor. is there really an issue with the lid state that i should know about? someone have a pointer to an acpi bug, perhaps?

Revision history for this message
Johannes Hessellund (osos) wrote :

Yes, there is really an issue with the lid state.

If
cat /proc/acpi/button/lid/LID/state
always returns:
state: closed
whether laptop is closed or open, you have an acpi bug...

But g-p-m NEVER does dpms on when lid state = closed.
The bug is fixed in g-p-m 2.17.1, where you're able to set a gconf-key to make it work.

Revision history for this message
pgf (pgf) wrote :

thanks. guess i need to look elsewhere -- the lid state seems to be working correctly, and more experimentation shows that dpms isn't working whether the lid is open or shut.

(to be clear -- the built-in screen powers down correctly, immediately, when the lid is closed, but the external monitor never does.)

thanks again.

Revision history for this message
drberg1000 (drberg1000) wrote :

> The bug is fixed in g-p-m 2.17.1, where you're able to set a
> gconf-key to make it work.

Which key would this be? I don't see it in /apps/gnome-power-manager on a feisty install running 2.17.91

--Dave

Revision history for this message
Bőle Pál (08akbp) wrote :

on my laptop the tft panel wont power off just blank, even if xset dpms force off say.
but if i sudo vbetool dpms off say, the panel turns off normally.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for gnome-power-manager (Ubuntu) because there has been no activity for 60 days.]

Revision history for this message
hirak99 (hirak99) wrote :

I am running Hardy, and I am facing the exact same problem with a desktop system. This monitor used to shutdown/standby for Gutsy, however. Now with or without the screen saver it does not shutdown.

Attached is the out of `gnome-power-manager --no-daemon --verbose`.

Also below is the result of `xset q`. I can force a standby with `xset force standby` option.

DPMS (Energy Star):
  Standby: 0 Suspend: 0 Off: 0
  DPMS is Enabled
  Monitor is On

Revision history for this message
Zach (v-launchpad-zach-sadecki-net) wrote :

I've got the same problem here. My output from `gnome-power-manager --no-daemon --verbose` looks almost identical to hirak99's.

This is with a fresh install of 8.04 beta. I did see the monitor turn off once, but never again. Now it stays on all night. `xset dpms force off` will properly turn off the monitor, and `xset dpms 0 0 600` turns it off after 10 minutes, just like it should. Of course, every restart or change to GPM causes xset to be turned back to all 0s.

Revision history for this message
Russ W. Knize (rknize) wrote :

I've had this problem ever since I got my LCD monitor (HP LP2065). The problem has been the same for edgy, feisty, gutsy, and hardy. It may have something to do with the Avocent SwitchView 1000 KVM between my desktops and my monitor, however my Windows box can put the display to sleep just fine regardless of how I have Windows setup to control it. I suppose it could also be a quirk with the graphics card in this box ("nVidia Corporation NV44 [GeForce 6200 TurboCache(TM)] (rev a1)").

After experimenting with the DPMS method used by gnome-power-manager, I was able to get it to work by using the "standby" method for:

/apps/gnome-power-manager/backlight/dpms_method_ac

I would try experimenting with all three settings for your particular cases. I restarted gnome-power-manager between each test, but this may not be necessary. Note that you have to actually wait for the screen saver to start before gnome-power-manager sets the DPMS settings for the power savings timeout (1 minute screen saver + 1 minute display sleep in my case). When looking at the output of "gnome-power-manager --verbose --no-daemon" for each method with a 1+1 minute timeout, I see (once the screensaver starts):

"BACKLIGHT parameters 60 0 0, method '2'" for "standby"
"BACKLIGHT parameters 0 60 0, method '3'" for "suspend"
"BACKLIGHT parameters 0 0 60, method '4'" for "off"

In my case, my monitor/KVM combo only responded to the "standby" method. YMMV.

Revision history for this message
BassKozz (basskozz+ubuntu) wrote :

This is simliar to the bug I posted here: https://bugs.launchpad.net/ubuntu/+bug/275308 Also on Bugzilla (http://bugzilla.gnome.org/show_bug.cgi?id=554247)

but I noticed this problem after switching to TwinView mode (from separate X sessions) on my dual-monitor setup.

Has anyone found a solution?

Revision history for this message
Russ W. Knize (rknize) wrote :

Have you tried my suggestions? Have you looked at gnome-power-manager logs?

Revision history for this message
BassKozz (basskozz+ubuntu) wrote :

Sorry for the delay Russ,

No I don't believe I have, but I am new to Linux, and I need some help trying your suggestions and finding the logs...
Can you please let me know what to do to better help?
Thanks,
-BassKozz

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.