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: <alpine.LFD.2.01.0908252114130.3218@localhost.localdomain>
Date:	Tue, 25 Aug 2009 21:20:18 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Zhenyu Wang <zhenyuw@...ux.intel.com>
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 Wed, 26 Aug 2009, Zhenyu Wang wrote:
> 
> We can't depend on any BIOS display config as you noted before our driver.

But you do. You depend on the even _less_ reliable existence of a VBT 
table.

> And our driver does more flexible config than VBIOS does.

If by "flexible" you mean "doesn't work in many more ways", then yes.

I have never EVER found a BIOS that didn't output to at least _some_ 
screen that is connected. That's fairly damn fundamental. Yet that is 
exactly what KMS screws up on some hardware right now.

Trust me, "flexible" is not the right word. 

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

And how about MacBook 2.1, which apparently also goes black?

And the Westmere thing? 

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

And dammit, if you cannot detect it, then don't try.

You'd actually be better off not trying your random crud, and instead
 - leave whatever connection the BIOS set up
 - let the user _tell_ you about other ones.

If you cannot reliably detect something, don't go off and use some random 
number generator. And quite frankly, depending on BIOS tables _is_ a 
random number generator. It may be that you just haven't learnt that yet, 
but maybe you could work on ACPI for a while to see what I mean.

Right now, there's not even any way to _override_ your incorrect guesses. 

So I can say "don't do mode-setting at all", but I can't say "use SVDO at 
1680x1050". So my screen goes black. And I happen to be in the enviable 
position of having known about the Mac Mini issues and the KMS thing - 
think about what happens to people that just try a new distro kernel, and 
suddenly there's nothing on the screen. 

			Linus
--
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/