Message-ID: <21d7e9970908252158q30d7e4fay587458b79cd0c36d@mail.gmail.com>
Date:	Wed, 26 Aug 2009 14:58:21 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Zhenyu Wang <zhenyuw@...ux.intel.com>,
	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>
Subject: Re: Linux 2.6.31-rc7

On Wed, Aug 26, 2009 at 2:13 PM, Linus
Torvalds<torvalds@...ux-foundation.org> wrote:
>
>
> On Wed, 26 Aug 2009, Dave Airlie wrote:
>> >
>> > 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.
>>
>> This isn't anything to do with redetection, and in the Mac case there isn't
>> even a BIOS table that you can really rely on since Apple hard coded all
>> this stuff into their EFI and Mac OSX drivers.
>
> That's really my point.
>
> There _is_ one sort of detection you could do: look at the actual state of
> the graphics chip.
>
> In other words, exactly the case you mention: don't trust any BIOS tables
> (they may not exist, and they _are_ broken in many cases) or silly EFI
> information (I guarantee that any firmware info will eventually be buggy:
> EFI is in no way going to be magically less buggy than BIOS tables have
> been).
>
> So what's left? You can still look at how the chip was programmed. If it's
> driving the VGA port, you can be pretty sure that there's a monitor
> attached. Sure, there might be something _else_ attached too, and I'm not
> saying that you cannot try to probe other things, but right now it seems
> that KMS totally throws away a free - and fairly reliable - piece of
> information. And replaces it with very unreliable information that
> definitely doesn't work.
>
> I'm all for looking at many different places to find 'the truth', but I'm
> very unhappy with KMS looks into BIOS tables, decides that there's a LVDS
> panel attached (there isn't), and then disables the VGA port that drives
> the monitor.
>
> That doesn't help _anybody_. It just results in a black screen. And I
> guarantee that this happens on several pieces of hardware, and no, it's
> not all just "crap Apple and EFI". One of the pieces of hardware it
> happens on is an Intel-only machine. Intel hardware, Intel firmware, Intel
> motherboard, Intel _everything_. And yes, KMS decides to drive a
> nonexistent LVDS display, rather than the one that the BIOS correctly
> booted up with.
>
>> Just because the BIOS manages to light up an output in now way effects
>> whether the driver can do the same.
>
> .. but if the BIOS drives one output, that should be a damn big hint that
> you shouldn't then just randomly pick another one!
>
> It sure as hell is a bigger hint than the ones you're using right now.
> Which is kind of my point here. Why are you arguing against a known bug?
>
>> I'm not sure why the mac-mini hack hasn't been merged I asked for it a
>> few times,
>> I'd rather the proper solution was merged but that seems to not have
>> happened either.
>
> I want to repeat: it's not just Mac Mini.
>
>> You have two special cases here,
>> a) mac mini - apple hw, needs hacks to workaround the fact that they do
>> something nobody else does with the hw and then don't tell you about it
>> in the hw. the hack from userspace should have been ported to the kernel
>> but I keep not seeing it.
>
> The thing is, the BIOS _does_ report it to the hardware: you could just
> read the hardware registers.
>
> But no. Instead the Intel KMS code discards the hardware registers, and
> reads the BIOS tables instead, finds a LVDS entry there, and uses that -
> and disconnects the entry that _was_ driving the monitor.
>
> Really. Do you seriously believe that because you found some random tables
> in the BIOS memory, it's more reliable than "oh, the BIOS set the hardware
> up to drive the SVDO output"?
>
> That's what I find irritating. We _know_ BIOS tables are random crap. We
> _know_ they are way less reliable than just asking the hardware where it
> is. But KMS still trusts the VBT data more than the fact that the chip has
> been programmed to output DVI/SVDO output.
>
>> b) pre-production SDV hardware for a mobile chipset without LVDS, here's
>> both pieces you get to keep them. LVDS isn't detectable on any hw, the
>> sanity assumption so far are you have a mobile chipset you must have
>> LVDS, you have an ACPI lid button you might have LVDS.
>
> Again, you say that, but you have absolutely nothing to back it up with.
>
> Here's a counter-argument: we _know_ that it's not detectable whether
> there's an LVDS panel is attached or not. So what should we do? Should we
> turn off the VGA1 connection that we can see that the BIOS programmed, and
> set things up for LVDS instead?
>
> That's f*cking _stupid_. Go ahead and program the LVDS panel *too*, but
> don't turn off the SDVO (or whatever) output that was also active!
>
> And quite frankly, if the BIOS didn't turn on the panel, then maybe the
> kernel shouldn't either. At least not until it gets a "lid open" event. So
> even the "go ahead and program LVDS too" part is quite debatable.
>
> In other words: it would be a lot saner to just keep whatever output mode
> that the machine booted with. Then, change it ONLY IF YOU DETECT SOMETHING
> ACTUALLY CHANGING.

So most of your arguments are valid and someone at Intel should probably
investigate it.

Some points though:
1. I know what hw you have, you reported bugs against only Apple and SDVs,
via Fedora we track a lot more hw, and we haven't seen this issue reported
on any production PC hardware.

2. LVDS is enabled by the BIOS so we read back the hw, its turned on even
on your SDV. So yes we shouldn't shut off VGA, but reading back the hw
isn't reliable either.

3. Here's the thing, we do detect something has changed, we detect we no
longer have a monitor connected on the mac mini because the routing
for the DDC pins is insane and need special treatment in the driver. So maybe
we get kms started and we fail when X tries to start or the first time the user
sets a mode or probes the hw. We also would really like to know some
information about
the monitor you plugged in so we don't do anything stupid to it.

so yes I think do better at failing is what is needed, its still
failing but its more
user friendly fail.

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