So as you probably know the trouble with ivy bridge is that it has two PLLs and it supports three monitors which I want to use. (sort of related: https://bugzilla.redhat.com/show_bug.cgi?id=836765) The same problem applies to randr but I don't know if this should be solved together with the kernel driver or separately. I think in my scenario I encounter several closely related issues: I have two "identical" monitors (Flatron W2442PE) connected to my notebook. One monitor is connected with HDMI and the other is connected with DVI, and the third monitor is the LVDS of the notebook. The trouble is that these external monitors have two very similar modes and it seems to randomly switch which of those is the preferred mode. According to xrandr they look like this: 1920x1080 (0x53) 138.5MHz +HSync -VSync +preferred h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 66.6KHz v: height 1080 start 1083 end 1088 total 1111 clock 59.9Hz 1920x1080 (0x54) 148.5MHz +HSync +VSync *current h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz This time the 0x53 mode is the preferred one for both monitors. Next time it could as well be the 0x54 one for one or both of them. I do not know if the monitors actually provide the different preferred modes or if linux assigns the preferred modes, but in both cases I think a workaround would be useful. The workaround could be: For ivy bridge, if there are three monitors of which two have the same modes but different preferred modes, then just override the preferred settings of one. It would be preferrable to use the fastest refresh rate anyway, right? First reason: linux will spam the console with messages like [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:7] on boot if the preferred modes of the two external monitors don't match. It will continue to spam it randomly in the console once every few minutes. Second reason: This is debateable but I think out of the box working of all three monitors is worth more than the slightly unexpected behaviour if the monitors do indeed have different preferred modes and just happen to have a matching mode. The alternative would be disabling the third output "somehow" until the user "selects" at least two matching modes. I am not really in favor of that because the user probably won't understand why the third output doesn't show up, maybe even randomly like in my scenario.
Can you please grab the raw edid from /sys/class/drm/card0-output_name/edid and copmare whether that stays the same when your preferred mode changes?
Ping. Christoph Haag, please provide the information requested in comment #1.
(In reply to comment #1) > Can you please grab the raw edid from /sys/class/drm/card0-output_name/edid > and > copmare whether that stays the same when your preferred mode changes? Christoph Haag, please provide the info.
Sorry, I was busy and did not have access to the monitors for some time. I have tried the two screens again several times now with linux 3.9 and could not reproduce the different modes. Of course I don't know if it only worked by accident now or it's some behaviour that has changed since then. I wasn't only thinking about the special case with those two exact screens but a general case where there were three screens have different preferred modes, but two of them support each other's preferred modes. If it ever happens again, I will gather EDID information, but I can't do much about it right now, unfortunately. In the meantime, this can be closed at will, I think.
Thanks a lot for checking back and please file a new report if something else pops up. We did indeed drop a few modes generated from EDIDs which shouldn't have been there ever, so not too surprising that 3.9 works better.