GNOME Bugzilla – Bug 660859
Power plugin should not fail to start if DPMS timeouts cannot be cleared
Last modified: 2012-03-09 12:00:55 UTC
(This bug report applies to the current git versions of the gnome-3-2 branches of gnome-settings-daemon and gnome-desktop) On my machine with the proprietary nvidia blob and xorg-server-1.10.4, gnome_rr_screen_set_dpms_mode() always fails. If it fails, then gsd_power_manager_start() returns FALSE. In effect, the power plugin treats failure to clear DPMS timeouts as fatal and refuses to start. This is obviously not the right behavior, especially considering that when the power plugin is running, gnome_rr_screen_set_dpms_mode() failures are *not* treated as fatal and simply generate a warning.
Created attachment 198194 [details] [review] patch to start power plugin with a warning if DPMS timeouts cannot be cleared
What's the error when the DPMS timeouts can't be set? I'm slightly concerned that the power plugin will do odd things if it can't set the DPMS mode with the binary driver. Thanks. Richard.
(In reply to comment #2) > What's the error when the DPMS timeouts can't be set? The error message is "Could not set DPMS timeouts".
What does "xset dpms 0 0 0" print? Thanks.
(In reply to comment #4) > What does "xset dpms 0 0 0" print? Thanks. Nothing; it succeeds (judging by the output of "xset q"). Similarly, "xset dpms $any $other $number" also succeeds.
(In reply to comment #5) > (In reply to comment #4) > > What does "xset dpms 0 0 0" print? Thanks. > > Nothing; it succeeds Hmm, oddball. Could you set a breakpoint on gnome_rr_screen_clear_dpms_timeouts and try to get the exit status of DPMSSetTimeouts -- i.e. the ret and rc variables. You can even use a printf if it's easier :) Thanks!
(In reply to comment #6) > Hmm, oddball. Could you set a breakpoint on gnome_rr_screen_clear_dpms_timeouts > and try to get the exit status of DPMSSetTimeouts -- i.e. the ret and rc > variables. You can even use a printf if it's easier :) Thanks! rc is 1 (meaning failure, if I understood X.h correctly) ret is 1 (meaning TRUE).
(In reply to comment #7) > rc is 1 (meaning failure, if I understood X.h correctly) rc=1 is BadRequest. I'll ask my X friends later what that means.
While investigating this bug I added lots of fprintfs to xset-1.2.2 source. And it turned out that, at least under the nvidia binary blob, DPMSSetTimeouts() and DPMSForceLevel() return BadRequest even when they succeed. Which is probably why xset completely ignores their return values. I have filed bug #660962 to ignore DPMSSetTimeouts() and DPMSForceLevel() return values in libgnome-desktop.
Okay, I've committed the gnome-desktop fix -- is this enough to close this bug now? Thanks.
(In reply to comment #10) > Okay, I've committed the gnome-desktop fix -- is this enough to close this bug > now? Thanks. I still think that failing to start a plugin on an error condition that is not fatal while the plugin is running is not good policy, but fixing that is no longer critical for my systems. Your call, basically :)
(In reply to comment #11) > Your call, basically :) Okay, we've talked and I agree that failing to set the dpms state is no reason to fail the plugin. Given the control-center and shell both use the interface this plugin provides, it's probably a good idea to make this always run. I've pushed your patch to master. Thanks. Richard