[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1282638912.2191.17.camel@localhost.localdomain>
Date: Tue, 24 Aug 2010 10:35:12 +0200
From: Ivan Bulatovic <combuster@....com>
To: Chris Wilson <chris@...is-wilson.co.uk>
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
jbarnes@...tuousgeek.org, eric@...olt.net
Subject: Re: i915: 2.6.36-rc2 wrong resolution on gdm start
On Tue, 2010-08-24 at 08:49 +0100, Chris Wilson wrote:
> On Tue, 24 Aug 2010 03:00:55 +0200, Ivan Bulatovic <combuster@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists