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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090826035840.GA16894@zhen-devel.sh.intel.com>
Date:	Wed, 26 Aug 2009 11:58:40 +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>
Subject: Re: Linux 2.6.31-rc7

On 2009.08.25 20:33:32 -0700, Linus Torvalds wrote:
> On Wed, 26 Aug 2009, Zhenyu Wang wrote:
> >
> > > In my experience, the BIOS setup doesn't reflect what outputs should be
> > > used at runtime, and certainly not the correct configuration of the
> > > enabled outputs.  For example, if we went to this, the giant monitor
> > > attached to my laptop that I actually look at would go unused.
> > 
> > yeah, normally VBIOS startup just needs or only can driver one pipe, so
> > we don't have any pre knowledge except detect everything.
> 
> Umm. What's your guys point, exactly?
> 

We can't depend on any BIOS display config as you noted before our driver.
And our driver does more flexible config than VBIOS does.

> The fact is, as-is, YOU DETECT THE WRONG OUTPUTS!
> 
> If you actually detected things _right_, none of this would be an issue. 
> But you don't. And you seem to have a really hard time even admitting 
> that. You try to re-detect things, and you SCREW UP.
> 

We know we have problem on Mac mini, this issue has been known for a while.
And Keith also posted patch at
	http://lists.freedesktop.org/archives/intel-gfx/2009-June/002843.html
but I don't know the status of this now.

> > we already have some mac relate bugs open, but please report on it so we
> > do have people with hardware to try and response. We have recently got a
> > MacBook, yakui is looking after the modesetting issue on it.
> 
> Quite frankly, I've reported these things several times. I've been open to 
> try patches. Nothing has ever come out of it. 
> 
> I have a Mac Mini that I reported as broken over a month ago. I have a 
> Westemere I've reported as not doing any DDC probing - and that I have to 
> disable the LVDS probing on entirely in order to not make KMS set up the 
> display to go to a non-existent LVDS port.
> 
> You claim that you "detect everything", but quite frankly, you don't. The 
> KMS code seems to assume that if it's a mobile chipset, it should have an 
> LVDS output - and whether anything is connected to that or not is totally 
> immaterial. There's clearly _zero_ "detection" going on.
> 

We've tried many ways to detect LVDS, but none is stable or actually work for
every chip. But now we have DMI quirks for some known no LVDS machine (including
Mac mini), and we detect through ACPI LID object for LVDS exist. 

-- 
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)