Monitor remains blanked with Intel Graphics

[Chuck McManis]

Running on a NUC5i7RYH, latest BIOS. ASUS Monitor connected via Display Port or HDMI
Running Xubuntu 16.04 - latest all current patches

Sometimes the monitor remains blanked even when the session has reactivated.

I have been able to reproduce this problem by letting the monitor remain in the 'blanked' state for > 60 minutes, or powering off the monitor. When the monitor is powered back on and the session is woken up with mouse or keyboard input, it does wake up but the monitor remains blanked.

I was able to prove to myself the session was awake by leaving it with terminal opened to full screen with VIM running on an NFS mounted file system. I could type and save at the black monitor screen and see that the file got updates from a different system. So the session is "live" but the computer has forgotten to re-establish the DisplayPort link.

An error appears in the lightdm logs about setting a CRTC, if you activate an alternate terminal (say with CTL-ALT-F1) and try `xrandr --output DP1 --auto` it also registers that CRTC error. HOWEVER, if you ssh in from a different machine, tell bash to export DISPLAY=:0 (set $DISPLAY to ':0') and then type 'xrandr --output DP1 --auto' the screen turns on again! This also happens on a Gigabyte BRIX system (same NUC reference design but in that case a core i3 rather than a Core i7).

To reproduce, turn off the monitor, wait an hour, and turn it on again.

You can also kill HUP the lightdm process and that will restart a new session (but open windows in the previous session are lost).

So interesting questions, why does typing xrandr "locally" give you the error but running it from an ssh session work?

Since xrandr and restarting the session can both "fix" the problem, the driver seems to know how to turn the display on if told correctly.

How can I find out where the code is getting the CRTC error?

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: lightdm 1.18.1-0ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: XFCE
Date: Thu May 12 20:33:01 2016
InstallationDate: Installed on 2016-05-08 (4 days ago)
InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
LightdmDisplayLog: (II) AIGLX: Suspending AIGLX clients for VT switch
LightdmLog:
 [+80180.09s] DEBUG: Seat seat0 changes active session to
 [+80189.53s] DEBUG: Seat seat0 changes active session to 64
 [+80222.67s] DEBUG: Seat seat0 changes active session to c4
 [+80222.67s] DEBUG: Session c4 is already active
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jan (jan-hendrik)]

Please try the patch mentioned here: https://bugs.launchpad.net/bugs/1308105

[Chuck McManis (chuck-mcmanis)]

This has worked to re-display my screen power is removed and then
re-applied to the monitor, I'm doing further testing to see if it also
fixes the issue with lockscreen blanking and sleeping.

On Thu, May 19, 2016 at 8:25 AM, Jan <email address hidden> wrote:
> Please try the patch mentioned here:
> https://bugs.launchpad.net/bugs/1308105
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1581302
>
> Title:
> Monitor remains blanked with Intel Graphics
>
> Status in lightdm package in Ubuntu:
> Confirmed
>
> Bug description:
> Running on a NUC5i7RYH, latest BIOS. ASUS Monitor connected via Display Port or HDMI
> Running Xubuntu 16.04 - latest all current patches
>
> Sometimes the monitor remains blanked even when the session has
> reactivated.
>
> I have been able to reproduce this problem by letting the monitor
> remain in the 'blanked' state for > 60 minutes, or powering off the
> monitor. When the monitor is powered back on and the session is woken
> up with mouse or keyboard input, it does wake up but the monitor
> remains blanked.
>
> I was able to prove to myself the session was awake by leaving it with
> terminal opened to full screen with VIM running on an NFS mounted file
> system. I could type and save at the black monitor screen and see that
> the file got updates from a different system. So the session is "live"
> but the computer has forgotten to re-establish the DisplayPort link.
>
> An error appears in the lightdm logs about setting a CRTC, if you
> activate an alternate terminal (say with CTL-ALT-F1) and try `xrandr
> --output DP1 --auto` it also registers that CRTC error. HOWEVER, if
> you ssh in from a different machine, tell bash to export DISPLAY=:0
> (set $DISPLAY to ':0') and then type 'xrandr --output DP1 --auto' the
> screen turns on again! This also happens on a Gigabyte BRIX system
> (same NUC reference design but in that case a core i3 rather than a
> Core i7).
>
> To reproduce, turn off the monitor, wait an hour, and turn it on
> again.
>
> You can also kill HUP the lightdm process and that will restart a new
> session (but open windows in the previous session are lost).
>
> So interesting questions, why does typing xrandr "locally" give you
> the error but running it from an ssh session work?
>
> Since xrandr and restarting the session can both "fix" the problem,
> the driver seems to know how to turn the display on if told correctly.
>
> How can I find out where the code is getting the CRTC error?
>
> ProblemType: Bug
> DistroRelease: Ubuntu 16.04
> Package: lightdm 1.18.1-0ubuntu1
> ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
> Uname: Linux 4.4.0-22-generic x86_64
> ApportVersion: 2.20.1-0ubuntu2
> Architecture: amd64
> CurrentDesktop: XFCE
> Date: Thu May 12 20:33:01 2016
> InstallationDate: Installed on 2016-05-08 (4 days ago)
> InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
> LightdmDisplayLog: (II) AIGLX: Suspending AIGLX clients for VT switch
> LightdmLog:
> [+80180.09s] DEBUG: Seat seat...

[Chuck McManis (chuck-mcmanis)]

I've run both my systems monitor's through a full idle->blank->sleep->wakeup cycle by setting the power managment settings to do that, and with this patch they both have come back. The final step will be to leave them overnight and verify I can wake them both up in the morning. Will update when I've done that.

[Chuck McManis (chuck-mcmanis)]

Ok, I've done the overnight test (monitors blanked) and both systems recovered (relit the monitors) in the morning. So for me at least the jkempke68 patch has fixed the problem.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Drew Lustro (drewlustro)]

For anyone running xfce4 with this bug driving them nuts, it may pertain to a known bug in xfsettingsd.

Check out the patch noted here: https://bugzilla.xfce.org/show_bug.cgi?id=11107#c53

Download the xfce4-settings source, apply the patch, increment with a non-maintainer version number (for no future apt-get conflicts once this gets an official fix), and reinstall your patched xfce4-settings.

The aforementioned screen blank patch fixed this bug that has been driving me nuts for weeks. I would lose my entire X session every single day as soon as the screen blanked... quite troublesome when you're trying to make linux work as your daily drive, haha.

I had to learn how to patch a .deb file properly in the process, but that was worth it too.

-- Hardware/Software --
GPU: GTX 970 over DisplayPort 1.2
Monitor: Dell P2715 (4K@60Hz, hardware rev A03)
OS: Xubuntu Xenial (16.04 LTS)
Manually patched xfce4-settings version: 4.12.0-2ubuntu1

Useful links on patching .deb's:
https://help.ubuntu.com/community/UpdatingADeb
http://www.cyberciti.biz/faq/appy-patch-file-using-patch-command/

[spike speigel (frail-knight)]

I'm experiencing this behavior with a Dell XPS 13 9360 Developer Edition

I'm not running xfce. I'm using stock Unity, but lightdm is running.