While in init3, resolution is native, KMS works fine, no problems at all. As soon as gdm starts it seems that TV1 output is recognized as connected even if it isn't so resolution on VGA output is degraded from native 1280x1024 to 1024x768 on startup.
I've disabled LVDS output with video=LVDS-1:d because the cable looses connection in certain lid positions.
2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and it came down to this commit:
9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Aug 18 13:20:54 2010 -0700
drm/i915: wait for actual vblank, not just 20ms
Waiting for a hard coded 20ms isn't always enough to make sure a vblank period has actually occurred, so add code to make sure we really have passed through a vblank period (or that the pipe is off when disabling).
This prevents problems with mode setting and link training, and seems to fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but on an HP 8440p instead. Hopefully also fixes https://bugs.freedesktop.org/show_bug.cgi?id=29141.
Signed-off-by: Jesse Barnes jbarnes@virtuousgeek.org Signed-off-by: Eric Anholt eric@anholt.net
:040000 040000 9941813d0f0bc4e141a87696d34f1d1b9087711b 2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on DELL Vostro 1310 is in question. Thanks,
Ivan
On Tue, 24 Aug 2010 03:00:55 +0200, Ivan Bulatovic combuster@gmx.com wrote:
While in init3, resolution is native, KMS works fine, no problems at all. As soon as gdm starts it seems that TV1 output is recognized as connected even if it isn't so resolution on VGA output is degraded from native 1280x1024 to 1024x768 on startup.
Interesting. I am chasing a spurious TV connection on SDVO that has been present since time immemorial. How certain are you that you've never have a false detection in earlier kernels? It may not have affected the choice of outputs, except sporadically, but it should be recorded in the debug logs with drm.debug=0x6.
Does this make any difference?
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo index ea2f4ab..e7ff378 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1454,7 +1454,7 @@ intel_sdvo_detect(struct drm_connector *connector, return connector_status_unknown; if (intel_sdvo->is_tv) { /* add 30ms delay when the output type is SDVO-TV */ - mdelay(30); + mdelay(100); } if (!intel_sdvo_read_response(intel_sdvo, &response, 2)) return connector_status_unknown;
Or (more likely):
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo index ea2f4ab..77c455b 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1216,8 +1216,8 @@ static int intel_sdvo_dpms(struct drm_encoder *encoder, in temp = I915_READ(intel_sdvo->sdvo_reg); if ((temp & SDVO_ENABLE) == 0) intel_sdvo_write_sdvox(intel_sdvo, temp | SDVO_ENABLE); - for (i = 0; i < 2; i++) - intel_wait_for_vblank(dev, intel_crtc->pipe); + + msleep(100);
status = intel_sdvo_get_trained_inputs(intel_sdvo, &input1, &input2);
On Tue, 2010-08-24 at 08:49 +0100, Chris Wilson wrote:
On Tue, 24 Aug 2010 03:00:55 +0200, Ivan Bulatovic combuster@gmx.com wrote:
While in init3, resolution is native, KMS works fine, no problems at all. As soon as gdm starts it seems that TV1 output is recognized as connected even if it isn't so resolution on VGA output is degraded from native 1280x1024 to 1024x768 on startup.
Interesting. I am chasing a spurious TV connection on SDVO that has been present since time immemorial. How certain are you that you've never have a false detection in earlier kernels? It may not have affected the choice of outputs, except sporadically, but it should be recorded in the debug logs with drm.debug=0x6.
Does this make any difference?
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo index ea2f4ab..e7ff378 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1454,7 +1454,7 @@ intel_sdvo_detect(struct drm_connector *connector, return connector_status_unknown; if (intel_sdvo->is_tv) { /* add 30ms delay when the output type is SDVO-TV */
mdelay(30);
mdelay(100); } if (!intel_sdvo_read_response(intel_sdvo, &response, 2)) return connector_status_unknown;Or (more likely):
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo index ea2f4ab..77c455b 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1216,8 +1216,8 @@ static int intel_sdvo_dpms(struct drm_encoder *encoder, in temp = I915_READ(intel_sdvo->sdvo_reg); if ((temp & SDVO_ENABLE) == 0) intel_sdvo_write_sdvox(intel_sdvo, temp | SDVO_ENABLE);
for (i = 0; i < 2; i++)intel_wait_for_vblank(dev, intel_crtc->pipe);
msleep(100); status = intel_sdvo_get_trained_inputs(intel_sdvo, &input1, &input2);-- Chris Wilson, Intel Open Source Technology Centre
Hi Chris. Well, I think that I had these problems before, around 2.6.28/2.6.29 but all I remember is that it was fixed relatively fast. Everything worked well untill 2.6.36-rc2 popped up. Not even sporadical events like these. What was strange about this that I wasn't able to kill TV connection with xrandr, so I was stuck with 1024x768 and all of a sudden upon subsequent restarts it somehow remembered that tv is disconnected and VGA resolution is native.
xrandr -q
TV1 disconnected (normal left inverted right x axis y axis) 848x480 (0x55) 14.5MHz h: width 848 start 849 end 912 total 944 skew 0 clock 15.4KHz v: height 480 start 481 end 512 total 513 clock 30.0Hz
cat /var/log/Xorg.0.log | grep TV
[ 27.733] (II) intel(0): Output TV1 has no monitor section [ 27.988] (II) intel(0): EDID for output TV1 [ 27.991] (II) intel(0): Printing probed modes for output TV1 [ 27.991] (II) intel(0): Output TV1 connected [ 27.991] (II) intel(0): Output TV1 using initial mode 1024x768
Above patches didn't help when applied to 2.6.36-rc2.
I'm going to compare dmesg between 2.6.35.3 and 2.6.36-rc2 with drm.debug=0x6. Thanks,
Ivan
On Tue, 24 Aug 2010 10:35:12 +0200, Ivan Bulatovic combuster@gmx.com wrote:
Above patches didn't help when applied to 2.6.36-rc2.
Would be useful to double check reverting the bad commit helps.
I'm going to compare dmesg between 2.6.35.3 and 2.6.36-rc2 with drm.debug=0x6. Thanks,
Aye that would be a useful check.
On Tue, 2010-08-24 at 09:50 +0100, Chris Wilson wrote:
On Tue, 24 Aug 2010 10:35:12 +0200, Ivan Bulatovic combuster@gmx.com wrote:
Above patches didn't help when applied to 2.6.36-rc2.
Would be useful to double check reverting the bad commit helps.
I'm going to compare dmesg between 2.6.35.3 and 2.6.36-rc2 with drm.debug=0x6. Thanks,
Aye that would be a useful check.
-- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Here are both dmesg outputs with drm.debug=0x6 in the attachements
cat dmesg.drm.35 | grep TV [ 1.006007] [drm:intel_tv_detect_type], No TV connection detected [ 26.391167] [drm:intel_tv_detect_type], No TV connection detected [ 26.539169] [drm:intel_tv_detect_type], No TV connection detected [ 26.805170] [drm:intel_tv_detect_type], No TV connection detected [ 26.953169] [drm:intel_tv_detect_type], No TV connection detected [ 31.935291] [drm:intel_tv_detect_type], No TV connection detected [ 32.083153] [drm:intel_tv_detect_type], No TV connection detected [ 32.352162] [drm:intel_tv_detect_type], No TV connection detected [ 32.500166] [drm:intel_tv_detect_type], No TV connection detected [ 32.819162] [drm:intel_tv_detect_type], No TV connection detected [ 32.967161] [drm:intel_tv_detect_type], No TV connection detected [ 42.666163] [drm:intel_tv_detect_type], No TV connection detected [ 42.814164] [drm:intel_tv_detect_type], No TV connection detected [ 43.083165] [drm:intel_tv_detect_type], No TV connection detected [ 43.231164] [drm:intel_tv_detect_type], No TV connection detected [ 43.500165] [drm:intel_tv_detect_type], No TV connection detected [ 43.648165] [drm:intel_tv_detect_type], No TV connection detected [ 47.134054] [drm:intel_tv_detect_type], No TV connection detected [ 47.281076] [drm:intel_tv_detect_type], No TV connection detected
cat dmesg.drm.36 | grep TV [ 1.487022] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set [MODE:0:NTSC 480i] [ 1.691016] [drm:intel_tv_detect_type], No TV connection detected [ 25.939358] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set [MODE:0:NTSC 480i] [ 26.143015] [drm:intel_tv_detect_type], No TV connection detected [ 26.264155] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set [MODE:0:NTSC 480i] [ 26.269980] [drm:intel_tv_detect_type], Detected S-Video TV connection [ 26.406164] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set [MODE:0:NTSC 480i] [ 26.419933] [drm:intel_tv_detect_type], Detected Composite TV connection [ 26.657428] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set [MODE:0:NTSC 480i] [ 26.670054] [drm:intel_tv_detect_type], Detected S-Video TV connection [ 27.171031] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set [MODE:54:1024x768] [ 32.772020] [drm:intel_tv_detect_type], No TV connection detected [ 32.874039] [drm:intel_tv_detect_type], No TV connection detected [ 33.090015] [drm:intel_tv_detect_type], No TV connection detected [ 33.192015] [drm:intel_tv_detect_type], No TV connection detected [ 33.473017] [drm:intel_tv_detect_type], No TV connection detected [ 33.575016] [drm:intel_tv_detect_type], No TV connection detected [ 42.800550] [drm:intel_tv_detect_type], Detected Component TV connection [ 42.916789] [drm:intel_tv_detect_type], Detected Component TV connection [ 43.034997] [drm:intel_tv_detect_type], Detected Component TV connection [ 46.486754] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set [MODE:0:NTSC 480i] [ 46.690019] [drm:intel_tv_detect_type], No TV connection detected [ 46.821272] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set [MODE:0:NTSC 480i] [ 46.833086] [drm:intel_tv_detect_type], Detected S-Video TV connection [ 46.964281] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set [MODE:0:NTSC 480i] [ 46.967099] [drm:intel_tv_detect_type], Detected Composite TV connection [ 47.132794] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set [MODE:57:]
I'll try to revert 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 and see if that helps.
Thanks for the confirmation Pekka. I've managed to change the resolution but gdm always starts with 1024x768 and upon login it gets 1280x1024, and sometimes the mouse pointer go out of bounds to the right edge of the screen but when I maximize windows it sticks to 1280x1024. When I start gnome-display-properties that invisible right portion of the screen dissapears.
Ivan, can you try this patch?
Linus is going to make some more snide comments if he sees just how many of these trivial-ish patches that I have pending...
---
If we need to wait until the next vblank for the register to be updated and to take effect, make sure the write is actually flushed to the register prior to sleeping.
Signed-off-by: Chris Wilson chris@chris-wilson.co.uk --- drivers/gpu/drm/i915/intel_tv.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c index d2029ef..19b9739 100644 --- a/drivers/gpu/drm/i915/intel_tv.c +++ b/drivers/gpu/drm/i915/intel_tv.c @@ -1157,10 +1157,13 @@ intel_tv_mode_set(struct drm_encoder *encoder, struct drm_display_mode *mode, I915_WRITE(dspbase_reg, I915_READ(dspbase_reg));
/* Wait for vblank for the disable to take effect */ - if (!IS_I9XX(dev)) + if (!IS_I9XX(dev)) { + POSTING_READ(dspbase_reg); intel_wait_for_vblank(dev, intel_crtc->pipe); + }
I915_WRITE(pipeconf_reg, pipeconf & ~PIPEACONF_ENABLE); + POSTING_READ(pipeconf_reg); /* Wait for vblank for the disable to take effect. */ intel_wait_for_vblank(dev, intel_crtc->pipe);
@@ -1268,11 +1271,15 @@ intel_tv_detect_type (struct intel_tv *intel_tv) DAC_C_0_7_V); I915_WRITE(TV_CTL, tv_ctl); I915_WRITE(TV_DAC, tv_dac); + POSTING_READ(TV_DAC); intel_wait_for_vblank(dev, intel_crtc->pipe); + tv_dac = I915_READ(TV_DAC); I915_WRITE(TV_DAC, save_tv_dac); I915_WRITE(TV_CTL, save_tv_ctl); + POSTING_READ(TV_CTL); intel_wait_for_vblank(dev, intel_crtc->pipe); + /* * A B C * 0 1 1 Composite
On Tue, 2010-08-24 at 10:21 +0100, Chris Wilson wrote:
Ivan, can you try this patch?
I've patched it, unfortunately it doesn't help. :( Dmesg is in attachement. Symptoms are the same.
Linus is going to make some more snide comments if he sees just how many of these trivial-ish patches that I have pending...
I don't think so, this is fun, I haven't had problems with intel drivers in months :D
If we need to wait until the next vblank for the register to be updated and to take effect, make sure the write is actually flushed to the register prior to sleeping.
Signed-off-by: Chris Wilson chris@chris-wilson.co.uk
Hi all,
On Tue, Aug 24, 2010 at 12:12 PM, Ivan Bulatovic combuster@gmx.com wrote:
Thanks for the confirmation Pekka. I've managed to change the resolution but gdm always starts with 1024x768 and upon login it gets 1280x1024, and sometimes the mouse pointer go out of bounds to the right edge of the screen but when I maximize windows it sticks to 1280x1024. When I start gnome-display-properties that invisible right portion of the screen dissapears.
I'm still seeing wrong resolution with my i915 Macbook with latest Linus' git. Is there a fix in the pipeline or should we start looking for a commit to revert? As a slab maintainer, I'm supposed to be able to work with -rc kernels and this particular bug is pretty damn annoying.
Pekka
On Sun, Aug 29, 2010 at 02:29:32PM +0300, Pekka Enberg wrote:
I'm still seeing wrong resolution with my i915 Macbook with latest Linus' git. Is there a fix in the pipeline or should we start looking for a commit to revert? As a slab maintainer, I'm supposed to be able to work with -rc kernels and this particular bug is pretty damn annoying.
I've been seeing a variety of strange behaviour since 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 too (I found I could narrow it down in http://lkml.org/lkml/2010/8/24/280 but the change mentioned there doesn't seem to help others). I've filed https://bugs.freedesktop.org/show_bug.cgi?id=29857 which summarises the different strange behaviour that I've seen generated and the steps I've used to reproduce them. Unfortunately this week I'm not going to have much time for the tests I was able to do last week.
On Tue, Aug 24, 2010 at 4:00 AM, Ivan Bulatovic combuster@gmx.com wrote:
While in init3, resolution is native, KMS works fine, no problems at all. As soon as gdm starts it seems that TV1 output is recognized as connected even if it isn't so resolution on VGA output is degraded from native 1280x1024 to 1024x768 on startup.
I've disabled LVDS output with video=LVDS-1:d because the cable looses connection in certain lid positions.
2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and it came down to this commit:
9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Aug 18 13:20:54 2010 -0700
drm/i915: wait for actual vblank, not just 20ms
Waiting for a hard coded 20ms isn't always enough to make sure a vblank period has actually occurred, so add code to make sure we really have passed through a vblank period (or that the pipe is off when disabling).
This prevents problems with mode setting and link training, and seems to fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but on an HP 8440p instead. Hopefully also fixes https://bugs.freedesktop.org/show_bug.cgi?id=29141.
Signed-off-by: Jesse Barnes jbarnes@virtuousgeek.org Signed-off-by: Eric Anholt eric@anholt.net
:040000 040000 9941813d0f0bc4e141a87696d34f1d1b9087711b 2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on DELL Vostro 1310 is in question. Thanks,
On Tue, Aug 24, 2010 at 4:00 AM, Ivan Bulatovic combuster@gmx.com wrote:
While in init3, resolution is native, KMS works fine, no problems at all. As soon as gdm starts it seems that TV1 output is recognized as connected even if it isn't so resolution on VGA output is degraded from native 1280x1024 to 1024x768 on startup.
I've disabled LVDS output with video=LVDS-1:d because the cable looses connection in certain lid positions.
2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and it came down to this commit:
9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Aug 18 13:20:54 2010 -0700
drm/i915: wait for actual vblank, not just 20ms
Waiting for a hard coded 20ms isn't always enough to make sure a vblank period has actually occurred, so add code to make sure we really have passed through a vblank period (or that the pipe is off when disabling).
This prevents problems with mode setting and link training, and seems to fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but on an HP 8440p instead. Hopefully also fixes https://bugs.freedesktop.org/show_bug.cgi?id=29141.
Signed-off-by: Jesse Barnes jbarnes@virtuousgeek.org Signed-off-by: Eric Anholt eric@anholt.net
:040000 040000 9941813d0f0bc4e141a87696d34f1d1b9087711b 2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on DELL Vostro 1310 is in question. Thanks,
FWIW, I saw this on my MacBook as well. I was debugging a boot time oops at the time so I just changed screen resolution in Gnome to fix it.
On wtorek, 24 sierpnia 2010 o 03:00:55 Ivan Bulatovic wrote:
While in init3, resolution is native, KMS works fine, no problems at all. As soon as gdm starts it seems that TV1 output is recognized as connected even if it isn't so resolution on VGA output is degraded from native 1280x1024 to 1024x768 on startup.
I've disabled LVDS output with video=LVDS-1:d because the cable looses connection in certain lid positions.
2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and it came down to this commit:
9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Aug 18 13:20:54 2010 -0700
drm/i915: wait for actual vblank, not just 20msWaiting for a hard coded 20ms isn't always enough to make sure a vblank period has actually occurred, so add code to make sure we really have passed through a vblank period (or that the pipe is off when disabling).
This prevents problems with mode setting and link training, and seems to fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but on an HP 8440p instead. Hopefully also fixes https://bugs.freedesktop.org/show_bug.cgi?id=29141.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>:040000 040000 9941813d0f0bc4e141a87696d34f1d1b9087711b
2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on DELL Vostro 1310 is in question. Thanks,
Ivan
I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=17301 for your bug report, please add your address to the CC list in there, thanks!
dri-devel@lists.freedesktop.org
-
Chris Wilson -
Ivan Bulatovic -
Maciej Rutecki -
Pekka Enberg -
Sitsofe Wheeler