For the three DPMS timing parameters (blank, suspend, off), xset enforces the restriction t1 <= t2 <= t3, which is suitable for absolute times. The actual behavior 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, and the "off" delay is similarly restricted. For example, running "xset dpms 10 20 30" results in a total delay to the "off" state of 60 minutes, not 30 minutes. This bug has also been posted at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149431 . The "xscreensaver-demo -prefs" interface to the DPMS timing parameters also suffers from this same problem. There, the t1<=t2<=t3 restriction is documented and silently enforced.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Is this still a problem? If it is, what makes you think the problem is actually with xset?
xset checks the parameters just so that it can give a more friendly error message than the BadValue you'd get from sending them to the Xserver, which does the same check: static int ProcDPMSSetTimeouts(ClientPtr client) { REQUEST(xDPMSSetTimeoutsReq); REQUEST_SIZE_MATCH(xDPMSSetTimeoutsReq); if ((stuff->off != 0)&&(stuff->off < stuff->suspend)) { client->errorValue = stuff->off; return BadValue; } if ((stuff->suspend != 0)&&(stuff->suspend < stuff->standby)) { client->errorValue = stuff->suspend; return BadValue; } But I've always believed these are appropriate because they are relative to the same baseline, the last input event - if they're being treated as relative to the previous timeout, that would be a bug in the X server, but the xset checks are not.
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.