Created attachment 39985 [details] dmesg output The system is Lenovo x200s(GM45 video) + dock + 1920x1200 monitor connected to dock station DP via passive DP-DVI adapter, internal display are off, external are used as a primary with the native resolution. From time to time monitor goes black (as no signal) and immediately return to the normal state, 2.6.35.8 has no such problem (but it unusable for me without drm_kms_helper.poll=N workaround).
Did you try the drm_kms_helper.poll=N workaround with 2.6.36 as well? The periodic nature would seem to correlate with the connection polling.
ops..., now I think that it always was with workaround, my /etc/rc.local #!/bin/sh -e if [ -e /sys/module/drm_kms_helper/parameters/poll ]; then echo "N" > /sys/module/drm_kms_helper/parameters/poll fi exit 0
Created attachment 41441 [details] [review] possible fix it revert commit 81a14b46846fea0741902e8d8dfcc6c6c78154c8 drm/i915/sdvo: Set sync polarity based on actual mode commit b599c0bca1e08a89a7fc4305bc84f4be30ada368 drm/i915/hdmi: Set sync polarity based on actual mode commit d6d952689a48375afb97f619f77d548f16d45a92 drm/i915/pch: Set transcoder sync polarity for DP based on actual mode
Ah, so you are saying you have a broken EDID.
from attached dmesg : Modeline 10:"1920x1200" 60 154000 1920 1968 2000 2080 1200 1203 1209 1235 0x48 0x9 0x9 - EDID tell that HSYNC + and VSYNC - , but it must be HSYNC + and VSYNC + ?
may be this is monitor problem, there was strange behaviour with old radeon 9600 agp ( https://bugs.freedesktop.org/show_bug.cgi?id=28935 ), but it work fine with newer radeon hardware (has been tested with rs790, rv740), currently it work with rv530 connected to the other input.
Presumably, commit d6d952689a48375afb97f619f77d548f16d45a92 drm/i915/pch: Set transcoder sync polarity for DP based on actual mode is the relevant commit. As I'm being lazy does inverting the logic for the sync modes make any different, so you would have "intel_dp->DP |= DP_SYNC_VS_HIGH;" only.
Only this does not help. diff -urN a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c --- a/drivers/gpu/drm/i915/intel_display.c 2010-12-10 01:17:27.000000000 +0300 +++ b/drivers/gpu/drm/i915/intel_display.c 2010-12-25 19:28:53.000000000 +0300 @@ -2043,15 +2043,11 @@ int reg; reg = I915_READ(trans_dp_ctl); - reg &= ~(TRANS_DP_PORT_SEL_MASK | - TRANS_DP_SYNC_MASK); + reg &= ~TRANS_DP_PORT_SEL_MASK; reg |= (TRANS_DP_OUTPUT_ENABLE | - TRANS_DP_ENH_FRAMING); - - if (crtc->mode.flags & DRM_MODE_FLAG_PHSYNC) - reg |= TRANS_DP_HSYNC_ACTIVE_HIGH; - if (crtc->mode.flags & DRM_MODE_FLAG_PVSYNC) - reg |= TRANS_DP_VSYNC_ACTIVE_HIGH; + TRANS_DP_ENH_FRAMING | + TRANS_DP_VSYNC_ACTIVE_HIGH | + TRANS_DP_HSYNC_ACTIVE_HIGH); switch (intel_trans_dp_port_sel(crtc)) { case PCH_DP_B: Is it diff right?
Using other DVI cable seems to solve this problem (it works fine without any quirks), I am sorry for noise.
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.