lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ