Bug 149431 - Inconsistent interpretation of DPMS timing parameters
Inconsistent interpretation of DPMS timing parameters
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
https://bugs.freedesktop.org/show_bug...
:
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2005-02-22 18:02 EST by Robert Nichols
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-15 16:54:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 3041 None None None Never

  None (edit)
Description Robert Nichols 2005-02-22 18:02:10 EST
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
Comment 1 Mike A. Harris 2005-03-06 11:57:59 EST
> 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.

Comment 2 Robert Nichols 2005-03-06 13:40:01 EST
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.
Comment 3 Mike A. Harris 2005-03-06 16:08:35 EST
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".


Comment 4 Robert Nichols 2005-03-06 17:17:57 EST
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 09:22:35 EDT
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.
Comment 6 Mike A. Harris 2005-04-15 16:54:09 EDT
Thanks for the URL.  We'll track it there now.

Setting status to "UPSTREAM".

TTYL

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