I previously chimed in on #97450. That's been marked resolved as of Linux 4.9, but my issue remains, so I'm filing this as a separate bug. If it's actually the same, it's fine by me to close this as duplicate and reopen #97450. I have a Dell XPS 13 9350. I usually connect to an external Philips 288P6LJEB with a USB-C to DisplayPort cable, running 3840x2160@60.0Hz. The monitor is configured to use DisplayPort 2.0. I'm primarily running Debian stable (jessie), with the following installed from backports: firmware-amd-graphics 20160824-1~bpo8+1 irqbalance 1.1.0-2~bpo8+1 iucode-tool 2.0-1~bpo8+1 libdrm-amdgpu1:amd64 2.4.71-1~bpo8+1 libdrm-intel1:amd64 2.4.71-1~bpo8+1 libdrm-nouveau2:amd64 2.4.71-1~bpo8+1 libdrm-radeon1:amd64 2.4.71-1~bpo8+1 libdrm2:amd64 2.4.71-1~bpo8+1 libegl1-mesa:amd64 12.0.3-1~bpo8+1 libegl1-mesa-drivers:amd64 12.0.3-1~bpo8+1 libgl1-mesa-dri:amd64 12.0.3-1~bpo8+1 libgl1-mesa-glx:amd64 12.0.3-1~bpo8+1 libglapi-mesa:amd64 12.0.3-1~bpo8+1 libvdpau1:amd64 1.1.1-1~bpo8+1 linux-base 4.3~bpo8+1 mesa-vdpau-drivers:amd64 12.0.3-1~bpo8+1 xserver-xorg-video-intel 2:2.99.917+git20160706-1~bpo8+1 Intermittently, the monitor will go blank for about 3 seconds. It's hard for me to say how much of this is the software, versus how much is the monitor: in general, this monitor is slow to wake up (both during power up and coming back from sleep), so it's possible that the original event is very brief and then it takes the monitor a couple of seconds to adjust back to where it should be. No messages from Linux correspond to these events. However, the resolution does get re-reported in Xorg.log: [ 2216.405] (--) intel(0): HDMI max TMDS frequency 600000KHz [ 2216.412] (II) intel(0): resizing framebuffer to 3840x2160 [ 2216.460] (II) intel(0): switch to mode 3840x2160@60.0 on DP1 using pipe 0, position (0, 0), rotation normal, reflection none [ 2217.663] (--) intel(0): HDMI max TMDS frequency 600000KHz [ 2219.749] (II) intel(0): resizing framebuffer to 3200x1800 [ 2219.750] (II) intel(0): switch to mode 3200x1800@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none [ 2220.431] (--) intel(0): HDMI max TMDS frequency 600000KHz [ 2220.439] (II) intel(0): resizing framebuffer to 3840x2160 [ 2220.454] (II) intel(0): switch to mode 3840x2160@60.0 on DP1 using pipe 0, position (0, 0), rotation normal, reflection none [ 2221.660] (--) intel(0): HDMI max TMDS frequency 600000KHz [ 2532.187] (II) intel(0): resizing framebuffer to 3200x1800 [ 2532.189] (II) intel(0): switch to mode 3200x1800@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none [ 2547.231] (--) intel(0): HDMI max TMDS frequency 600000KHz [ 2547.242] (II) intel(0): resizing framebuffer to 3840x2160 [ 2547.270] (II) intel(0): switch to mode 3840x2160@60.0 on DP1 using pipe 0, position (0, 0), rotation normal, reflection none [ 2549.206] (II) intel(0): resizing framebuffer to 3200x1800 [ 2549.209] (II) intel(0): switch to mode 3200x1800@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none [ 2559.262] (--) intel(0): HDMI max TMDS frequency 600000KHz [ 2559.278] (II) intel(0): resizing framebuffer to 3840x2160 [ 2559.300] (II) intel(0): switch to mode 3840x2160@60.0 on DP1 using pipe 0, position (0, 0), rotation normal, reflection none [ 2560.521] (--) intel(0): HDMI max TMDS frequency 600000KHz DP1 is the laptop's own display, which is turned off (through GNOME configuration) when I'm connected to the monitor. The reported resolution always looks correct and unchanging, so I'm not sure what it means that the framebuffer is being "resized." I have seen this issue on every version of Linux I've tried: 4.6 and 4.7 installed from Debian backports, every version of 4.8 built from source, and now 4.9rc2.
I apologize, I misspoke on a couple of points and should correct them. In the Xorg logs above, DP1 is (apparently) the external display, while eDP1 is the laptop display. However, after watching more closely, it turns out these logs *don't* correlate with the screen blanks. Instead, they apparently happen while the screen is locked with GNOME's screen lock. I've noticed this monitor repeatedly complains about "No video input" when the screen is locked, rather than going to sleep as expected, and it seems like this correlates with some sort of flapping over which display should be primary. But that would be a separate issue, and personally it's less pressing to me than the monitor blanking.
Sorry, one last correction: the monitor is configured to use DisplayPort 1.2, not 2.0. And then an update: the issue persists with Linux built from drm-intel-nightly 2016y-10m-28d-18h-28m-33s (commit 5ec329fd58f6e8ae6542219cec286619e2cd2590).
Try configuring the monitor to use DisplayPort 1.1 if possible. I have been having this issue for a while and just this morning decided to poke around the monitor settings. Switching the monitor to 1.1 fixed the problem. My gear. Dell XPS 13 9350, AOC u3477pqu 3440x1440@59.94Hz The USB Type-C to DP adapter does claim to support DisplayPort Version 1.2, so I am not sure which piece is at fault yet.
My monitor can be switched to DisplayPort 1.1, but if I do that, I drop down to either a lower resolution or a 30Hz refresh rate. I can only run 3840x2160@60.0Hz with DisplayPort 1.2. I would still consider this a bug even if blanking does not occur with DisplayPort 1.1. I can add some more information: This issue still occurs with drm-intel-nightly 2016y-11m-10d-09h-29m-41s (commit eb88955cdc6a1f4dabff6bc27747c1c9e9a3aaef). I actually have two of the same monitor, one at home and another at the office. For some reason, the monitor at the office blanks much more often than the one at home. They both do it, but the one at home will run for hours without blanking, while the one at the office sometimes has fits where it blanks several times per minute. I'm really not sure how to debug something like that, but I'm happy to try suggestions. I have tried swapping out the DisplayPort cable I use at the office, but that didn't make any noticeable change.
I have noticed today that either switching from HDMI to mDP (Lenovo X250, Intel HD 5500; via docking station), or rather using the "modesetting" X.org driver (instead of "intel") fixed this issue for me: I do not had the external screen going off temporarily the whole afternoon. I have also switched the DP settings of the monitor (Dell U2715H), but am pretty certain to have used 1.2 at the end again (like before).
Hello Brett. I'm sorry about the delay until getting back to you. Is the bug still valid with the latest kernel (preferable from drm-tip) ?
Timeout - please reopen if problem still persist with the latest kernels (preferable from drm-tip).
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.