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 nouveau.debug=VBIOS=trace,DISP=debug,I2C=debug,DRM=debug in the kernel commandline (or otherwise passed to the module). Also mention how the monitor is connected.
Created attachment 104544 [details] boot.log 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
Two comments/questions: (1) 1:10 slim[256]: (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. (2) 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[256]: (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] boot.log 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: nouveau.debug=VBIOS=trace,DISP=debug,I2C=debug,DRM=debug,drm.debug=0xe You should have: nouveau.debug=VBIOS=trace,DISP=debug,I2C=debug,DRM=debug drm.debug=0xe
Created attachment 104604 [details] boot.log 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
s/xdpms/xset dpms/
*** 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.
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.