With nouveau drivers (current versions: kernel 3.15.9, xf86-video-nouveau-1.0.10, xorg-server-1.15.0; however the issue exists since several years)
"xset dpms force off" (or standby/suspend) does not work here as it should:
In all three cases, the monitor switches off for about 20 seconds but then switches on again.
The issue is completely reproducible and does not occur with the proprietary nvidia-drivers.
I am rather sure that nothing (except perhaps nouveau drivers themselves) causes any activity which might cancel the effect of "xset dpms force off":
This is already proved by the fact that it works with the proprietary nvidia-drivers, but I also checked many times that no suspectible task is running (and besides systemd the bug has occured also with openrc and with a minimal number of started services).
As mentioned, the problem exists since several years, so I do not think that any of the recent changes referred to in bug 76483 is related to this.
The bug you reference was about DP. But display stuff got a substantial rework in 3.16 (with an eye to DP) and even more changes are queued for 3.17. Would you mind giving the linux-3.17 branch a shot (http://cgit.freedesktop.org/nouveau/linux-2.6/log/?h=linux-3.17)? If that doesn't help, please provide a boot log with
in the kernel commandline (or otherwise passed to the module). Also mention how the monitor is connected.
Created attachment 104544 [details]
With kernel 3-17 (boot log attached) there is indeed a change:
Now the monitor does not react at all on "xset dpms force off".
The monitor is connected over DVI
1:10 slim: (EE) module ABI major version (13) doesn't match the server's version (15)
That seems a little unhappy... I hope that's not referring to the ddx's module. I guess you have an old module? As long as nouveau's not involved in this, it shouldn't matter.
Did you try to do a "xset dpms force off" in that log, or was that not included. In case it wasn't included, could you?
Lastly, I forgot that the drm core may also provide some useful information. Would you mind adding "drm.debug=0xe" to the kernel command line in addition to the nouveau.debug setting I mentioned earlier, and provide a log which also includes you trying to "xset dpms force off"?
(In reply to comment #3)
> 1:10 slim: (EE) module ABI major version (13) doesn't match the
> server's version (15)
This was the v4l driver. I recompiled, but unsurprisingly, it does not change anything concerning the reported problem.
> Did you try to do a "xset dpms force off" in that log
This produced no output in the log, also not with the following:
> Would you mind adding "drm.debug=0xe" to the kernel command line
This did not change the output, either. Still no output when calling
xset dpms force off
I will attach the new boot log, but it is practically the same.
Created attachment 104594 [details]
As in the previous log, some obviously unrelevant information (like disk or network initialization messages) have been removed manually by me.
You misunderstood my suggestion... you have:
You should have:
Created attachment 104604 [details]
Still no output with "xdpms force off" (tried several times).
At a few minutes later (I cannot associate to an action of me) there appeared:
[kernel] nouveau T[ VBIOS][0000:01:00.0] inc() == 3
[kernel] nouveau T[ VBIOS][0000:01:00.0] dec() == 2
*** Bug 83244 has been marked as a duplicate of this bug. ***
My display re-enabe resume issue (#83244) resolved for me with http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=a68e95365a4248d3f58c8663e4513c79273ac704 which references this ticket. Thus the duplicate marker. Feel free to rectify this, if not correctly done.
I do not have physical access to the machine with the card in the next months, so I cannot confirm/test anything.
I can confirm that the regression reported in comment #2 that I bisected to d55b4af909bc16f7982c2b8b8656f0898158627b is now fixed as of 80ad99da8bd213e12b925407f1c97a303aa8f87f (which pulled in 5838ae610ff36777b8fce6f353c2417980c1a1fa). Additionally I haven't been able to reproduce the case that this bug was originally opened for yet, (prior to 3.17 I could but it was always a bit finicky). Still, it's probably too early to say that its fixed for sure; I have a slightly different card than Martin's (a 10de:042f, NVIDIA Corporation G86 [Quadro NVS 290] (rev a1)).
By accident, I am now traveling and have access on the machine for 1 or 2 days.
I installed linux-3.17.2, and have still exactly the same faulty behaviour as described in the original posting:
xset dpms force off holds for about 20 seconds and then switches on again.
For what it's worth, I see similar behavior with the Nouveau driver on OpenSUSE 13.2 (kernel 3.16.7-24, xf86-video-nouveau-1.0.11-1.3)
My office machine has two displays connected to a GTS450. Both displays go into standby mode. After a short delay -- I haven't measured by hand but the aforementioned 20-second value sounds about right -- the secondary display comes out of standby. Near as I can tell, this behavior only affects the secondary display. I can also confirm that the behavior did not occur when using the proprietary nVidia drivers.
Another data point that may be useful when diagnosing the problem: I'm also using the nVidia card for audio. I'm away from the office for a few days but I'm reasonably confident that both displays are connected via DVI and that my speakers are connected to the secondary display's audio line-out jack. Is it possible that the secondary display's inability to remain in standby mode is somehow audio-related?
I don't know why this issue was marked as FIXED.
The behaviour hasn't changed since my first posting.
I am not using audio from nvidia, so at least in my case this is certainly not related.
I haven't been at the nvidia machine for a while.
Sometimes during the previous months the problem has indeed been fixed.