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
