Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 149431 - Inconsistent interpretation of DPMS timing parameters
Summary: Inconsistent interpretation of DPMS timing parameters
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: 3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2005-02-22 23:02 UTC by Robert Nichols
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-15 20:54:09 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated 3041 None None None Never

Description Robert Nichols 2005-02-22 23:02:10 UTC
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):

How reproducible:

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 foundation
Kernel:     kernel-2.6.10-1.766_FC3

Comment 1 Mike A. Harris 2005-03-06 16:57:59 UTC
> 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', 
               `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
               mode, the second is for the `suspend' mode, and  the 
third  is
               for  the  `off'  mode.  Setting these values implicitly
               the DPMS features.  A value of zero disables a
particular mode.

Comment 2 Robert Nichols 2005-03-06 18:40:01 UTC
The help page for xscreensaver-demo says the following for the DPMS

   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.

Comment 3 Mike A. Harris 2005-03-06 21:08:35 UTC
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

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

Comment 4 Robert Nichols 2005-03-06 22:17:57 UTC
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.

Comment 5 Mike A. Harris 2005-04-15 13:22:35 UTC
Please report this to X.Org at 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

Comment 6 Mike A. Harris 2005-04-15 20:54:09 UTC
Thanks for the URL.  We'll track it there now.

Setting status to "UPSTREAM".


Note You need to log in before you can comment on or make changes to this bug.