Bug 82527 - xset dpms force {off,standby,suspend} returns after ~20 seconds (GeForce 8400 GS)
Summary: xset dpms force {off,standby,suspend} returns after ~20 seconds (GeForce 8400...
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
: 83244 (view as bug list)
Depends on:
Reported: 2014-08-12 20:47 UTC by Martin Väth
Modified: 2017-09-16 20:20 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

boot.log (143.08 KB, text/plain)
2014-08-13 07:53 UTC, Martin Väth
no flags Details
boot.log (140.23 KB, text/plain)
2014-08-14 00:15 UTC, Martin Väth
no flags Details
boot.log (157.35 KB, text/plain)
2014-08-14 07:20 UTC, Martin Väth
no flags Details

Description Martin Väth 2014-08-12 20:47:21 UTC
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.
Comment 1 Ilia Mirkin 2014-08-12 20:51:56 UTC
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.
Comment 2 Martin Väth 2014-08-13 07:53:44 UTC
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
Comment 3 Ilia Mirkin 2014-08-13 17:36:51 UTC
Two comments/questions:


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.


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"?
Comment 4 Martin Väth 2014-08-14 00:12:03 UTC
(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.
Comment 5 Martin Väth 2014-08-14 00:15:41 UTC
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.
Comment 6 Ilia Mirkin 2014-08-14 00:18:38 UTC
You misunderstood my suggestion... you have:


You should have:

nouveau.debug=VBIOS=trace,DISP=debug,I2C=debug,DRM=debug drm.debug=0xe
Comment 7 Martin Väth 2014-08-14 07:20:07 UTC
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
Comment 8 Martin Väth 2014-08-14 07:22:46 UTC
s/xdpms/xset dpms/
Comment 9 michael.weirauch 2014-09-30 11:36:38 UTC
*** Bug 83244 has been marked as a duplicate of this bug. ***
Comment 10 michael.weirauch 2014-09-30 11:38:34 UTC
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.
Comment 11 Martin Väth 2014-09-30 12:14:25 UTC
I do not have physical access to the machine with the card in the next months, so I cannot confirm/test anything.
Comment 12 Jamie Heilman 2014-10-04 18:36:12 UTC
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)).
Comment 13 Martin Väth 2014-11-07 07:21:35 UTC
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.
Comment 14 Jimmie Mayfield 2015-09-12 15:24:13 UTC
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?
Comment 15 Martin Väth 2016-06-26 16:11:17 UTC
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.
Comment 16 Martin Väth 2017-09-16 20:20:35 UTC
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.