From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Description of problem: The timing parameters for "xset dpms n1 n2 n3" are described as absolute, and the command enforces n1 <= n2 <= n3. What actually happens is that each parameter is an incremental time from the previous state change. Because of the enforcement of the numerical values, the interval between blanking the screen and entering suspend mode must be at least as long as the inactivity time for the initial blanking. Version-Release number of selected component (if applicable): xorg-x11-6.8.1-12.FC3.21 How reproducible: Always Steps to Reproduce: 1. Run "xset dpms 1 2 3". 2. Start your stopwatch and wait. Actual Results: When the watch reads 1 minute, the screen goes blank. When the watch reads 3 minutes, the monitor enters suspend mode. When the watch reads 6 minutes, the monitor powers off. Expected Results: Suspend mode should have been entered at the 2 minute mark, and power down should have occurred at the 3 minute mark. Additional info: The same behavior results when the parameters are entered in "xscreensaver-demo -prefs". Video card: ATI Radeon 9200SE Driver: "radeon" from X.org foundation /usr/X11R6/lib/modules/drivers/radeon_drv.o /usr/X11R6/lib/modules/drivers/ati_drv.o Kernel: kernel-2.6.10-1.766_FC3
> xset dpms n1 n2 n3 are described as absolute Described where? "man xset" gives the following: -dpms The -dpms option disables DPMS (Energy Star) features. +dpms The +dpms option enables DPMS (Energy Star) features. dpms flags... The dpms option allows the DPMS (Energy Star) parameters to be set. The option can take up to three numerical values, or the `force' flag followed by a DPMS state. The `force' flags forces the server to immediately switch to the DPMS state spec- ified. The DPMS state can be one of `standby', `suspend', `off', or `on'. When numerical values are given, they set the inactivity period (in units of seconds) before the three modes are activated. The first value given is for the `standby' mode, the second is for the `suspend' mode, and the third is for the `off' mode. Setting these values implicitly enables the DPMS features. A value of zero disables a particular mode.
The help page for xscreensaver-demo says the following for the DPMS parameters: Standby After If Power Management Enabled is selected, the monitor will go black after this much idle time. (Graphics demos will stop running, also.) Suspend After If Power Management Enabled is selected, the monitor will go into power-saving mode after this much idle time. This duration should be greater than or equal to Standby. Off After If Power Management Enabled is selected, the monitor will fully power down after this much idle time. This duration should be greater than or equal to Suspend. The restriction that each successive value be greater than the previous makes little sense if these are incremental times. Though the manpage doesn't mention it, the xset command enforces that same restriction: $ xset dpms 5 4 5 illegal combination of values standby time of 5 is greater than suspend time of 4 If you are suggesting that it is intentional that each successive interval be at least as large as the previous one, then this report needs to be rewritten as an enhancement request to remove that restriction.
You are confusing the documentation and operation of one application (xscreensaver-demo) with the documentation and operation of another entirely different application (xset). The documentation of xset describes how xset operates, and the documentation for xscreensaver-demo documents how xscreensaver-demo operates. While it may potentially be confusing to some people that 2 different programs implement a certain functionality in a different manner, one by using absolute parameters, and another by using relative parameters, that in itself is not a bug in either application, but rather a design choice by the developers of both applications. The solution, is to follow the documentation of xset when using xset to set DPMS values, and to follow the documentation of xscreensaver-demo when using xscreensaver-demo. This is not a bug, it is misinterpretation of documentation, so closing as "NOTABUG".
I am not confused at all. You are incorrect in stating that one interface uses absolute parameters and the other uses relative. Both interfaces require absolute parameters (T1 <= T2 <= T3). For xset, that restriction is undocumented, but is enforced by the program. For xscreensaver-demo, the restriction is documented and sliently enforced. Entering the same numeric values in the two interfaces results in the same messages being sent to the X server. In both cases the actual behavior of those parameters is incremental, and that is a bug.
Please report this to X.Org at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates. Setting status to "NEEDINFO", awaiting upstream bug report URL for tracking.
Thanks for the URL. We'll track it there now. Setting status to "UPSTREAM". TTYL