Summary: | Inconsistent interpretation of DPMS timing parameters | ||
---|---|---|---|
Product: | xorg | Reporter: | Bob <rnichols42> |
Component: | App/xset | Assignee: | Xorg Project Team <xorg-team> |
Status: | RESOLVED NOTABUG | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | high | CC: | alan.coopersmith, jay.cotton, jeremyhu, roland.mainz |
Version: | 6.8.1 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | 2011BRB_Reviewed | ||
i915 platform: | i915 features: |
Description
Bob
2005-04-15 13:36:14 UTC
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.