[Intel-gfx] [PATCH] drm/i915: prefer VBT modes for SVDO-LVDS over EDID

[Egbert Eich]

Chris Wilson writes:
 > On Sun, Jun 09, 2013 at 11:28:12PM +0200, Daniel Vetter wrote:
 > > On Sun, Jun 9, 2013 at 11:16 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
 > > > On Sun, Jun 09, 2013 at 10:58:38PM +0200, Daniel Vetter wrote:
 > > >> In
 > > >>
 > > >> commit 53d3b4d7778daf15900867336c85d3f8dd70600c
 > > >> Author: Egbert Eich <eich at suse.de>
 > > >> Date:   Tue Jun 4 17:13:21 2013 +0200
 > > >>
 > > >>     drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC
 > > >>
 > > >> Ebgert Eich fixed a long-standing bug where we simply used a
 > > >> non-working i2c controller to read the EDID for SDVO-LVDS panels.
 > > >> Unfortunately some machines seem to not be able to cope with the mode
 > > >> provided in the EDID (specifically they seem to not be able to cope
 > > >> with a 4x pixel mutliplier instead of a 2x one).
 > > >>
 > > >> Since it took forever to notice the breakage it's fairly safe to
 > > >> assume that at least for SDVO-LVDS panels the VBT contains fairly sane
 > > >> data. So just switch around the order and use VBT modes first.
 > > >>
 > > >> Cc: Egbert Eich <eich at suse.de>
 > > >> Cc: Chris Wilson <chris at chris-wilson.co.uk>
 > > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524
 > > >> Cc: stable at vger.kernel.org
 > > >> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
 > > >
 > > > I can accept the argument that we need to prefer the VBT mode here to
 > > > paper over the apparent regression, but to not pass on the full EDID
 > > > modes seems dubious.
 > > 
 > > I'm not sure there's any value in additional modes. We can't really
 > > support frequency switching over sdvo (it'd very likely require a
 > > mutliplier change) and for everything else we only ever let the fixed
 > > mode through the fixup hook.
 > 
 > I am trying not to generalise from the broken behaviour on this machine.
 > On another machine, there may be some value in the extra modes.
 > Select the sanest default we can, then let the user go nuts with the
 > extra information.

While I'm not a fan of setting non-native modes on panels this seems
to be a requirement in some environments - not sure if there are any
real world use cases but at least many QA test scenarios seem to include 
such modes.
So adding the EDID modes (unflagging the preferred bit!) would be what 
I'd opt for - admittedly for a very selfish reason: it will spare me 
of lengthy, pointless discussions with some partners' QA departments 
next time we update the Intel driver.

Once again we go out of our ways to accomodate the most broken
devices by imposing more limitations on all others as well. At 
one point we may even have to give in face the grim reality and 
start blacklisting some of the broken crap.

And since we are so much into bikeshedding here - maybe you could
fix my name in the comment ;)

Cheers,
	Egbert.