linux-kernel - Re: Linux 2.6.31-rc7

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090910054705.GA1014@zhen-devel.sh.intel.com>
Date:	Thu, 10 Sep 2009 13:47:05 +0800
From:	Zhenyu Wang <zhenyuw@...ux.intel.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Eric Anholt <eric@...olt.net>, mailing54 <mailing54@...k.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Airlie <airlied@...hat.com>,
	dri-devel@...ts.sourceforge.net, Ma Ling <ling.ma@...el.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"Zhao, Yakui" <yakui.zhao@...el.com>,
	Keith Packard <keithp@...thp.com>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>
Subject: Re: Linux 2.6.31-rc7

On 2009.08.25 21:20:18 -0700, Linus Torvalds wrote:
>
> And how about MacBook 2.1, which apparently also goes black?
> 

Linus, sorry for reply this old thread. 

I just handed on one MacBook with 945GM, and tried to find out
the reason of black screen. It is TV detection that caused it.

MacBook routes integrated TV DAC to mini-DVI port too, like for VGA.
Our TV detect does load detect, which trys to set a mode onto TV port
and checked back its status. This TV load-detect makes the LVDS black
on MacBook.

It looks our load detect function has problem that when we pick
up one crtc, we don't check if its has a fb. During first TV detect,
choosed crtc obviously has no fb, it would fail in modesetting when
setting plane surface. This might have effect on the purpose of load-
detect process. I'll see how it should be fixed. But even if I hacked
plane setting with all zeros, screen still goes black on my MacBook,
although TV detect return is right that there's none found. 

So this blank issue is within detect process, if you try to load fbcon
or X later, setting mode is fine on LVDS. That's why build fbcon in
kernel might workaround this issue.

I don't know much about our TV detect method details, but looks like
here we should check current TV status when system start. Otherwise
it seems we can't stopping blank the screen...So I did a temp hacking
like,

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 5b1c9e9..f3ecbaa 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1451,8 +1451,18 @@ intel_tv_detect(struct drm_connector *connector)
 	struct intel_output *intel_output = to_intel_output(connector);
 	struct intel_tv_priv *tv_priv = intel_output->dev_priv;
 	struct drm_encoder *encoder = &intel_output->enc;
+	struct drm_i915_private *dev_priv = connector->dev->dev_private;
 	int dpms_mode;
 	int type = tv_priv->type;
+	static int first_detect = 1;
+
+	if (first_detect) {
+		first_detect = 0;
+		if (!(I915_READ(TV_CTL) & TV_ENC_ENABLE))
+			return connector_status_disconnected;
+		else
+			return connector_status_connected;
+	}

 	mode = reported_modes[0];
 	drm_mode_set_crtcinfo(&mode, CRTC_INTERLACE_HALVE_V);

which makes LVDS working, but I haven't tested with mini-DVI <-> S-Video.
I'm not sure if this is ideal enough for this, but first get port states in
system startup for initial setup, and userspace could check and set required
config later seems sane to me, as you have also suggested to do.

This patch doesn't aim to be upstream, we may set the state in priv struct
to check boot state, but I'd like to hear others' comment about this.

thanks.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)