Re: DPMS not working in 4.5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Saturday, August 28, 2010 09:55:07 am Duncan did opine:

> gene heskett posted on Fri, 27 Aug 2010 23:22:19 -0400 as excerpted:
> > It did not survive the reboot, so I've "xset dpms 250 300 600" and
> > will test shortly by leaving it alone once I get caught up with the
> > email.
> > 
> > Where, if kde (or the pclos versions of drakex) cannot set for a
> > default, is there some place in the /etc/X11 tree where I can add or
> > change this so it works automatically when x is started?
> 
> OK, so you can at least use xset to verify the settings, and to set it
> each time you restart X (it's an X setting, so restarting X will
> normally make it reset, no full reboot needed).  That's progress. =:^)
> 
> I don't know much about PCLinuxOS except that it's based on Mandriva,
> which I haven't used since I switched to Gentoo back in 2004.  But the
> generic X and KDE stuff will likely apply.
> 
> First point: Altho they're sometimes set in the same places, DPMS and
> screensaver settings are logically separate, from X's perspective. 
> That's why xset lists them separately.
> 
> On modern display hardware, generally LCDs of some type these days, but
> to a lessor extent but still true to some degree, on half-modern CRTs
> as well, the "warm-up time" time the display used to take to come back
> to life is almost non-existent.  As such, screen savers as such are
> generally an anachronism, unless you happen to prefer seeing the screen
> still active and don't care about the additional power use vs simply
> having them turn off.  Similarly, it seems a lot of monitors return
> fast enough from full suspend mode, which is low enough power they
> don't even have an off unless you physically switch them off, that
> they've basically done away with standby as well.  The result is that
> DPMS standby/suspend/off often mean the same thing, and the monitor
> will enter suspend) at the first timeout, traditionally standby.
> 
> At least, that's what I've observed here, on quite a lot of hardware.

Here, my tests last nite, by setting a 180 240 300, the first two were 
ignored, and it went down at 306 seconds.  So here, it would seem only the 
off time is used for an lcd monitor, a SamSung 205bw.
 
> Meanwhile, note that unlike CRTs, LCDs (particularly desktop models,
> laptop models are a bit different due to the battery constraints they
> work under) often use very nearly the same energy in "on but screen
> blanked" "black" state, as they do in full-white state.  This is
> because the lamps powering them often remain at full power as long as
> the monitor is on, with "black" simply meaning the LCDs are set to full
> opaque mode, letting virtually no light thru.  (Laptop displays and
> desktop units with "dyanamic contrast" are often exceptions to this,
> turning the lamp down for dark scenes, as an all-black display
> obviously is, both reducing power usage and resulting in a higher
> "dynamic contrast" rating.)  So again, even a screen-blanking screen
> saver may not actually save any energy over simply leaving the thing
> on, and LCDs generally don't have the burn-in problems of CRTs or
> plasma displays, so yet again, either simply leaving the thing in
> normal operating mode, or going ahead and triggering full suspend, is
> generally the way to go.
> 
> Of course, those with a reason to use a console locker (enter password
> to resume) may still want to run a screen saver for that, since that's
> the timeout mechanism used there, but again, that's an entirely
> separate function from the display suspend/power-down functionality.
> 
> Now that /that's/ dealt with...
> 
> There's two ways you can automate your DPMS settings.  One is using the
> normal xorg.conf, or a file with the same DPMS settings dropped in
> xorg.conf.d if you're running xorg-server 1.8 or higher.  (FWIW, 1.9
> just came out a few days ago, and that's what I'm running now.  I
> upgraded from one of the release candidates, which I'd been running for
> a few weeks. The xorg.conf.d directory makes things MUCH simpler! =:^)
> 
> The other would be simply sticking a bash script in your kde startup,
> that automates the xset stuff you're using now.
> 
And I found this in rc.sysinit:
# Turn off DPMS for livecd
dpms=`grep -i dpms /etc/X11/xorg.conf|grep -i false`

if strstr "$cmdline" livecd ; then
    if [ -z "$dpms" ]; then
perl -pi -e "s|"DPMS"|"DPMS\"" "\"false"|" /etc/X11/xorg.conf
  fi
fi

The option line in xorg.conf is just "Option" "DPMS" to which I have added 
an "Enable".

> Let me know which way you want to go, and if you want to try the
> xorg.conf (.d) method, the version you're running and whether you
> already have a config or are going "xorg.conf-less" at present, and we
> can take it from there.  (This assumes of course that whatever
> proprietary drivers you might be running use the standard xorg.conf
> options... I don't do servantware, see the sig, so I'll help you if
> it's standardized, if not, you're on your own or find help from someone
> else.)
> 
> Or, if you know anything about shell scripts, you can likely figure out
> the xset thing on your own, and similarly with xorg.conf, if you know
> anything about it, or know how to read manpages and/or your nvidia
> driver docs.

I was of a mind to do a shell script, I seem to be at least functional at 
those.  The question is where do I put the invocation so its in effect.  I 
am the only user.

Another question too, if I reboot but don't log in right away, will it 
work?  Recalling that /var/log/Xorg.0.log says it is enabled at the point 
where x starts, so something even later in the sequence is killing it, 
which I believe is after the login on modern systems.

Suggestions welcome.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"Whom are you?" said he, for he had been to night school.
		-- George Ade
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.


[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux