On Fri, 30 Sep 2011 10:58:26 -0700 Keith Packard <keithp@xxxxxxxxxx> wrote: > On Fri, 30 Sep 2011 18:32:35 +0200, Daniel Vetter <daniel@xxxxxxxx> wrote: > > > Ok, this is way over my head, just checked whether the patch does what it > > claims to - nice exercise in reading dp modeset code ;-) > > Yeah, it's purely heuristic -- the VBT contains a mode which was > originally for the LVDS. It's unclear whether it should ever be applied > to an eDP panel, but absent other information, it seems like we should > at least consider it. > > Many LVDS panels don't bother to include an EDID rom, or the vendor > didn't bother to hook up the DDC wire; presumably it's cheaper for them > to stick more data in the VBIOS than add hardware. However, there are > some LVDS panels with EDID roms which contain *incorrect* mode data for > the panel (amazing, I know), and so the driver prefers to use the VBT > data when both are present. > > eDP, on the other hand, doesn't require any additional wiring (at least) > to connect up the DDC channel, and eDP panels are required to provide > EDID data. So far, in my (very small) sample set, I've got one machine > which provides accurate VBT *and* EDID data (an HP 2540p) and one > machine which provides inaccurate VBT data but accurate EDID data (a > MacBook air). So, I just decided to prefer the EDID data. > > One option would be to extract the current mode from the hardware when > the driver starts and use that if present. But, that might mean that > you'd get different modes depending on whether the machine booted with > the lid closed or open, which seems like a bad plan. More than that, I think eDP *requires* an EDID, and it sounds like even the Air has one (and if any machine didn't, you know it would be an Apple). So I'm definitely in favor of this change. -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
