Bug 13199 - Monitor turns off when internal screensaver is activated
Summary: Monitor turns off when internal screensaver is activated
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.3 (2007.09)
Hardware: All All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-12 07:25 UTC by Petr Svoboda
Modified: 2010-10-20 01:51 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
revert monitor blanking to pre 6.7 behaviour (2.38 KB, patch)
2008-02-14 11:34 UTC, Petr Svoboda
no flags Details | Splinter Review

Description Petr Svoboda 2007-11-12 07:25:19 UTC
When I activate internal screensaver with blanking on (e.g. xset s activate s blank), monitor is turned off. It is able to resume correctly, but I think this behaviour is not wanted, because I can use dpms for this and at least basic KDE screensaver sets blanking on, so it is hard to turn it off.

I got this behaviour after upgrading from xf86-video-ati-6.6.3 and xorg-1.2 to
xf86-video-ati-6.7.195 and xorg-1.4. When I use xf86-video-ati-6.6.3 with 
xorg-1.4, internal screensaver is working as with xorg-1.2. I am using CRT monitor and ATI Radeon 9250.

I was able to track it down to RADEONBlank function in radeon_display.c in xf86-video-ati. When I comment out lines with ...->funcs->dpms(...,DPMSModeOff), screensaver don't anymore turn monitor off. Obviously, it is not fix.

I think this is also triggered when X server is started, reset and when switching between X server and text console - in all these cases is monitor turned off and on again - it disappears with my "not-fix".
Comment 1 gsr.bugs 2007-11-14 12:57:14 UTC
I was going to report the same thing, as old behaviour was pretty nice:
"xset s 300 300": make the screen go black in 5 minutes
"xset dpms 600 600 600": and then make it turn off in another 5 (10 from start)

Now "s" will let you choose between off with "xset s blank" or the
moire inducing cross pattern with X logo with "xset s noblank", but
no way to make it black but still give time to avoid a start/stop cycle.

Old behaviour, even if what the man page says contradicts it, was
the most complete (if I want animations eating CPU, even if slow, I
will install xlock, xscreensaver or something like that, which I just
had to do to get a black screensaver). New behaviour forces CRT tubes
and LCD backlights a bit too much without option to have the two phase
power off. And in the case of CRTs, it is even worse, as I doubt a high frequency pattern is nice for the driving circuits (at least I saw it
moves slightly, so no burn in if using fast cycle time as "xset s 300 30").

A less extreme pattern would be better (or even just show the X logo in
faded colours, without any bg pattern), if there is no way to go back to
"s makes screen black". Yes, I tried "xset dpms 100 900 900" to test if
first level would be OK, but it seems this monitor does the same for
all modes.

Comment 2 Petr Svoboda 2008-02-14 11:34:45 UTC
Created attachment 14313 [details] [review]
revert monitor blanking to pre 6.7 behaviour

With this patch applied, "xset s activate s blank" will blank the video output but will not turn monitor off. So it should work like in version 6.6.3 and before.

Only tested with one CRT monitor, so I don't know if it will work with different configurations.
Comment 3 Petr Svoboda 2008-04-19 12:24:01 UTC
The patch still works for xf86-video-ati-6.8.0.
Comment 4 Alex Deucher 2010-10-19 15:57:35 UTC
turning off saves more power.
Comment 5 gsr.bugs 2010-10-19 16:39:10 UTC
That is what DPMS was doing. Now the only way to have a progressive turn off is running yet another process.
Comment 6 Petr Svoboda 2010-10-20 01:51:55 UTC
Hmm, this is sad, you just ignore CRT monitors. Using DPMS is not option for CRT, because after power off/on it takes some time before colors stabilize.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.