From: Linus Torvalds <torvalds@linux-foundation.org>
To: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Eric Anholt <eric@anholt.net>, mailing54 <mailing54@plzk.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dave Airlie <airlied@redhat.com>,
dri-devel@lists.sourceforge.net, Ma Ling <ling.ma@intel.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
"Zhao, Yakui" <yakui.zhao@intel.com>,
Keith Packard <keithp@keithp.com>
Subject: Re: Linux 2.6.31-rc7
Date: Tue, 25 Aug 2009 21:20:18 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0908252114130.3218@localhost.localdomain> (raw)
In-Reply-To: <20090826035840.GA16894@zhen-devel.sh.intel.com>
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
next prev parent reply other threads:[~2009-08-26 4:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-22 1:26 Linus Torvalds
2009-08-22 3:09 ` Regression: Linux 2.6.31-rc7 lost sensors on asus mobo Gene Heskett
2009-08-22 3:47 ` Linus Torvalds
2009-08-22 12:56 ` Gene Heskett
2009-08-22 6:12 ` Robert Hancock
2009-08-22 10:54 ` Stefan Richter
2009-08-22 13:48 ` Gene Heskett
2009-08-22 14:38 ` Stefan Richter
2009-08-22 19:55 ` Gene Heskett
2009-08-22 13:40 ` Gene Heskett
2009-08-23 10:56 ` Linux 2.6.31-rc7 Geert Uytterhoeven
2009-08-26 5:06 ` KOSAKI Motohiro
2009-08-25 17:25 ` mailing54
2009-08-25 18:11 ` Linus Torvalds
2009-08-25 21:37 ` mailing54
2009-08-25 22:07 ` Linus Torvalds
[not found] ` <1251239637.26348.20.camel@gaiman.anholt.net>
2009-08-26 1:51 ` Zhenyu Wang
2009-08-26 3:33 ` Linus Torvalds
2009-08-26 3:47 ` Dave Airlie
2009-08-26 4:13 ` Linus Torvalds
2009-08-26 4:58 ` Dave Airlie
2009-08-26 17:12 ` Linus Torvalds
2009-08-26 17:18 ` Jesse Barnes
2009-08-26 6:26 ` Eric Anholt
2009-08-26 6:35 ` Dave Airlie
2009-08-26 3:58 ` Zhenyu Wang
2009-08-26 4:20 ` Linus Torvalds [this message]
2009-09-10 5:47 ` Zhenyu Wang
2009-08-26 10:09 ` ykzhao
2009-08-30 22:01 ` Tino Keitel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.01.0908252114130.3218@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=eric@anholt.net \
--cc=jbarnes@virtuousgeek.org \
--cc=keithp@keithp.com \
--cc=ling.ma@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mailing54@plzk.org \
--cc=yakui.zhao@intel.com \
--cc=zhenyuw@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome