Created attachment 120693 [details] dmesg Steps to reproduce: Boot the computer; log in at the lightdm prompt. Use the window manager of your choice, or none. Possibly observe slight tearing at the desktop, which was not present at the login prompt. Open an instance of urxvt. Open a second urxvt. Both windows appear briefly, then within three seconds the screen goes black. Watch for a few minutes and observe that the screen spends about five seconds out of every sixty displaying the desktop, and the remainder of the time black. Occasionally the monitor displays a "no signal" message, when the black periods are sufficiently prolonged. Happens every time; opening a single instance of Chromium can also be used in place of the two urxvt instances. System architecture: x86_64 Kernel version: 4.1.13 Linux distribution: NixOS git head as of 2015-12-05 (also tried unstable as of 2015-12-25, and 15.09 stable, which is dated 2015-12-14). Machine: Gigabyte Core i3-5010U (GB-BXi3H-5010) Display connector: HDMI
Created attachment 120694 [details] xrandr --verbose
Created attachment 120695 [details] intel_reg dump --all --verbose
I neglected to mention that if I remotely kill either of the urxvt instances, the display recovers within about ten seconds. I can start and stop symptoms any number of times without rebooting, by starting and stopping programs.
Irene - I'm really sorry about this delay until getting back to you. Is this problem still valid on newer kernels? If yes then please provide new logs dmesg and card0/error (if applicable). See https://01.org/linuxgraphics/documentation/how-report-bugs.
Jari, That's okay! It does still happen, and I even still have the affected machine. Through further experimentation, I found that what was happening was that the actual fastest pixel clock which the integrated GPU could output was slower than what X was trying to use. So to work around it, I either reduce the total resolution, or reduce the framerate. It is possible that this is actually the monitor's fault; the modeline that it was using came from the monitor's EDID, and I have reproduced a similar issue on a different machine with the same monitor. If it's the monitor to blame, I don't know that it's really a problem for freedesktop to fix... It would be handy at the very least to be able to configure X not to drop back into the default highest mode the monitor suggests, if it's ever hot-swapped, but I don't see anywhere in the X configuration that that sort of setting could be hooked onto. I also theorized that the intermittent behavior was the result of allocating more video memory, but from cursory use of Intel's GPU tools, I was unable to find support for this. I stopped looking into it at that point, because I had a workaround already. I'll plug the original machine that the report came from back in at some point in the next couple weeks, and get you logs from it; I'll also try to get logs from the other affected machine, for comparison. Irene
Irene look like the issue is fixed and is a problem with the monitor and the settings. I'm setting this bug as resolved but please feel free to add details. if you thing the problem is not solved on the kernel side do please add more info.
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.