On Thu, May 26, 2016 at 4:39 PM, Mario Kleiner
<mario.kleiner.de@xxxxxxxxx> wrote:
> This reverts commit 013dd9e03872
> ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")
>
> This commit introduced a regression into stable kernels,
> as it reduces output color depth to 6 bpc for any video
> sink connected to a Displayport connector if that sink
> doesn't report a specific color depth via EDID, or if
> our EDID parser doesn't actually recognize the proper
> bpc from EDID.
>
> Affected are active DisplayPort->VGA converters and
> active DisplayPort->DVI converters. Both should be
> able to handle 8 bpc, but are degraded to 6 bpc with
> this patch.
>
> The reverted commit was meant to fix
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
>
> A followup patch implements a fix for that specific bug,
> which is caused by a faulty EDID of the affected DP panel
> by adding a new EDID quirk for that panel.
>
> DP 18 bpp fallback handling and other improvements to
> DP sink bpc detection will be handled for future
> kernels in a separate series of patches.
>
> Please backport to stable.
>
> Signed-off-by: Mario Kleiner <mario.kleiner.de@xxxxxxxxx>
> Acked-by: Jani Nikula <jani.nikula@xxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx
> Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
I wonder whether we shouldn't just move this into the DP code, and
instead of looking at the edid (which is just pass-through for dp->vga
dongles) we should only look at dpcd values? Or maybe only look at the
edid value if the sink is native DP, and not when it's a dongle.
That would probably also avoid the quirk, and that quirk seems a bit fishy.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
