[Intel-gfx] [Patch 0/3] DRM/I915: Use the child device array to decide whether the given HDMI/DP should be initialzied

[ykzhao]

On Mon, 2009-09-21 at 22:09 +0800, Adam Jackson wrote:
> On Mon, 2009-09-21 at 11:08 +0800, Zhenyu Wang wrote:
> > On 2009.09.21 10:30:29 +0800, ykzhao wrote:
> > > On Sat, 2009-09-19 at 04:00 +0800, Adam Jackson wrote:
> > > > On Fri, 2009-09-18 at 08:53 +0800, ykzhao wrote:
> > > > > On Fri, 2009-09-18 at 03:20 +0800, Adam Jackson wrote:
> > > > In particular, for mobile parts the child device array seems to always
> > > > contain an entry for LFP_TYPE.  However, it appears that addin_offset in
> > > > that entry is non-zero iff LVDS really is present.  I'm still collecting
> > > > more ROMs to verify this, but so far it looks pretty consistent.
> > >
> > > On most boxes it is reliable and can be used to decide whether the
> > > LVDS/TV should be initialized. But after I check the vbios collected
> > > from Jesse, I find that it is not reliable.
> > > 
> > >    On some boxes the definition of child device is incorrect. In such
> > > case it can't be used to decide whether the LVDS/TV should be
> > > initialized.
> > 
> > I doubt on the real gain of these patches, like boot time decrease, etc, in
> > consider on unreliable data from VBT...I don't think a longer list of output
> > types showed in xrandr has any problem for user, no? Or we just show connected
> > outputs in xrandr by default, and xrandr --verbose give you all possible outputs?
> 
> It's merely a cosmetic bug for DisplayPort and SDVO, sure.  I don't
> think that's an excuse, but it does make it less urgent.
> 
> For LVDS it is not a cosmetic bug.  Consider the failure modes:
> 
> a) LVDS present, but KMS claims it's not present.  You now have, at
> best, a laptop that can only drive external displays.  Assuming it
> actually has external connectors to drive, of course; some machines
> don't, in which case you've now made the machine an expensive
> paperweight.
> 
> b) LVDS not present, but KMS claims it is.  DRM masters like X and
> plymouth will get very confused.  If they start with a cloning placement
> heuristic, you'll be wedged into 1024x768 on all displays; Gnome will
> place the panels on the interior output rectangle, so your panel will be
> floating in the middle of the screen for no reason, windows will
> maximize to less than the full screen... and it won't be obvious that
> you need to turn LVDS off to fix it.  If they start with a spanning
> placement heuristic, you'll have a large dead region off to one side of
> the logical screen; hope that's not where your panels are.
> 
> It's clearly better to fail towards case b), because weird is better
> than useless.  Right now though we hit case a) for machines where
> internal LVDS is connected but no lid switch is present in ACPI.
Have you such a machine in your hand? There is no LID but LVDS is
present.

Can you send the vbios.dump and acpidump to me?
Thanks.
> 
> And - like I said - so far I'm finding a perfect correlation between
> addin_offset!=0 and LVDS actually being present.  I'd like to know what
> that field actually means.
> 
> - ajax