When the output is turned off via XRandr and turned on again with the same mode while another output is a clone mode, the first output won't be recovered but remains blank. In short, % xrandr --output LVDS1 --mode 1024x768 % xrandr --output VGA1 --mode 1024x768 where both shown correctly, % xrandr --output LVDS1 --off % xrandr --output LVDS1 --mode 1024x768 where LVDS1 is still blank although xrandr reports it's on. The issue can be reproduced on IronLake and SandyBridge with 2.6.37-rc6. Untested on other platforms. Looking down the problem, it seems related with DPMS. The DPMS is declared as ON in drm_crtc_helper_set_config() by the patch in commit bf9dc102e284a5aa78c73fc9d72e11d5ccd8669f, but it wasn't actaully turned on the device. Also, the sysfs entries of dpms are totally bogus. LVDS1 shows always Off, and once doing after on and off, VGA1 can be also Off forever. A temporary fix patch is attached below.
Created attachment 40392 [details] Fix patch
Novell bug: https://bugzilla.novell.com/show_bug.cgi?id=659619
I've forwarded the patch to dri-devel@lists.freedesktop.org.
Any updates on this?
Handled-By : Takashi Iwai <tiwai@suse.de> Patch : https://bugzilla.kernel.org/attachment.cgi?id=40392
Handled-By : Keith Packard <keithp@keithp.com> Patch : https://patchwork.kernel.org/patch/530921/
Fixed by commit 811aaa55ba21ab37407018cfc01770d6b037d3fb .
The commit above doesn't fix the all cases, as I mentioned in the LKML thread. The example of xrandr above is fixed, yes. But the problem remains a case like S4 (possible S3, too). Namely, % xrandr --output LVDS1 --off % xrandr --output VGA1 --mode 1024x768 then go to S4, unplug the VGA, then resume. Now you have no output in VGA1 even after enabling VGA1 (unless you explicitly change the mode again) since DPMS is set still to OFF. This is because of the inconsistent DPMS values kept in device properties and crtc. For fixing it, a similar patch like in comment 1 is needed.
Chris, Takashi, is this already resolved in the meantime?
Not fully, see comment 8.
*** Bug 33702 has been marked as a duplicate of this bug. ***
As comment 8 mentioned, after applying 811aaa55ba21ab37407018cfc01770d6b037d3fb to 2.6.37 kernel, blank screen still occur when combining s3(suspend/resume) operation. I can reproduce the blank screen with the following steps.: 1. connect VGA cable to netbook, output will switch to external display only 2. close lid to enter S3 (suspend) 3. open lid to exit from S3 (external display will back to light again, which works as expected） 4. unconnect VGA cable from netbook (unfortunately, LVDS is still black, but ssh with xrandr show LVDS is connected and with 1024x600 mode set) 5. connect VGA cable again (external display is on, which work as expected) 6. unconnect VGA cable from netbook without going into S3 (ok, this time LVDS is on which works as expected.)
yeah, I reproduced the issue following the comment 8 steps with the latest kernel commit (drm-intel-next)da3cc9202697a44057c1bd3ad685689375f1fe0c
Chris/Jesse, any plan to fix this?
Created attachment 62372 [details] remove connector dpms field, use property I think Takashi is on the right track, but I'd go a little further and remove the connector dpms field altogether. Seems like it would be nice to have a get_dpms hook as well for the connector as well, so we don't rely on the cached value in the property. I think this works for Takashi's case, but I've run into another mode setting bug that prevents me from knowing for sure. Takashi, can you try this against one of your problem kernels to see if it helps?
Hrm, I got an infinite loop of drm_connector_set_dpms() and drm_helper_connector_dpms() at starting X, and the system crashed immediately...
I applied the patch mentioned in comment 15 in 2.6.37-2 kernel, system crash at the start up.
Well, this bug has been open for over a year, with no useful updates in six months. Any chance of it getting fixed any time soon? This bug actually causes system crashes in some cases, see https://bugs.freedesktop.org/show_bug.cgi?id=36515 (comment 29).
Takashi, can you just push your patch to intel-gfx and get Daniel to pick it up?
I haven't met with this problem with the recent kernel, so I'm not sure whether it's still needed. Maybe partly because now the hotplug in X intel driver is enabled in the test system (while it was disabled at the time I posted this bug). Also, the patch leads to a crash by some reason. I'll submit the patch once after I confirm that the inconsistent DPMS state is still present, and fix the crash loop by patch.
Well, I have no problem reproducing the blank screen problem on a 3.3.2 kernel. This bug is still very much there.
Kamil, safe when you actually have the same test system as Takashi, it's very likely that you have a different bug (and maybe not a regression even). If that's the case, please open a new bug report with the usual details, preferrably on bugs.freedesktop.org.
Ok closing this one out. Takashi, please re-open if you still see this. Kamil, please file a new bug for your issue at bugs.freedesktop.org with all the info requested at http://intellinuxgraphics.org/how_to_report_bug.html.