[Intel-gfx] Valid DP connection without EDID?
Takashi Iwai
tiwai at suse.de
Mon Sep 17 10:16:49 CEST 2012
Hi Adam,
At Fri, 14 Sep 2012 11:25:03 -0400,
Adam Jackson wrote:
>
> On 9/14/12 10:19 AM, Takashi Iwai wrote:
> > Hi,
> >
> > we've got a machine showing a ghost DP2 output on a docking station.
> > The docking station has only one DP port and it's connected to DP1.
> > As a result, we get an DP2 active output containing the bogus VESA
> > standard modes 1024x768, 800x600, 640x480 although it's not connected
> > at all.
> >
> > Looking a bit deeply on it, it seems that the connector gives actually
> > the valid DPCD. So intel_dp_detect() returns
> > connector_status_connected. But since there is no real connection,
> > EDID isn't obtained. Thus of course no valid modes set.
>
> Can you be more specific here? What DPCD does it return?
It shows "DPCD: 110a820100030181"
> Does it claim
> to be a branch device? We don't currently get that case right, try for
> instance plugging in a DP->VGA pigtail.
Well, the port doesn't exist physically at all. The docking station
has only one physical DP output although it exposes two. (And the
machine has one another built-in DP port as DP3, but it works well.)
So it's definitely a hardware problem. But we can still work around
it.
> > A quick patch below adds (moves) a check of EDID and returns the
> > disconnected state when no valid EDID is returned. An open question
> > is whether this is really safe. Is there any case where no valid EDID
> > is returned but the connection is still valid?
>
> DisplayPort requires EDID. There may be a platform method for obtaining
> it for eDP, but for normal DP it has to exist over AUXCH.
>
> DVI and HDMI require it too, in fact. The only one that doesn't is VGA.
OK, so a workaround like my patch (just checking the validity of EDID)
won't bring regressions in theory?
thanks,
Takashi
More information about the Intel-gfx
mailing list