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

[Adam Jackson]

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20090921/2cb70ff9/attachment.sig>