On Fri, May 06, 2016 at 10:03:06PM +0200, Mario Kleiner wrote:
On 05/06/2016 08:27 PM, Ville Syrjälä wrote:
On Mon, Mar 28, 2016 at 01:52:44AM +0200, Mario Kleiner wrote:
Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
received a potential fix that was backported to stable. While that patch itself is correct for treating DP video sinks with "unknown color depth", it uncovered some lack in our general EDID 1.3 handling, and in how we treat DP->DVI/VGA, causing the fall back of Intel DP to 6 bpc / 18 bpp in cases where it shouldn't fall back. That leads to unhappy neuroscience/medical users of Intel gpus which need their DP->DVI or DP->VGA display devices to operate at at least 8 bpc without dithering.
The following three patches try to improve our EDID handling and Intel DP to try harder to detect the proper bpc to avoid these regressions for DP-DVI and DP-VGA. The third patch tries to fix FDO bug 105331 without causing general unhappiness of other users.
Thanks for the feedback.
It would seem simpler to me to move the 18bpp fallback into intel_dp.c and only do it for native DP sinks/downstream ports. That way we should avoid the need for any EDID quirks IIUC.
I think that specific EDID quirk in patch 3/3 for that FDO bug we'd always need, because that specific panels EDID reports 8 bpc capability by setting the "DFP 1.x compliant TMDS" bit in its EDID 1.3, but according to the FDO bug it needs to be driven with 6 bpc + dithering for good results.
If we just do the fallback for DP, then I don;t think we need any changes to the EDID parser, and hence no quirk either.
Do you agree with patch 1/3? That would avoid kms drivers needing to work out DFP compliant displays.I think we could probably make the assumption that anything that has EDID 1.3 is 8 bpc capable? DVI spec seems to require that for anything DVI, and i'd assume any VGA DAC manufactured in the last 20 years would have at least 8 bpc?
Wrt. 18 bpp fallback you mean putting it into intel_dp_legacy_bpc() from patch 2/3 or similar and checking that the sink is really not an active DVI or VGA converter?
Yeah, I'd just check the downstream port type, and do the 18bpp fallback only for native DP if the sink didn't give us a bpc. For everything else 8bpc seems like a reasonable default (unless the port caps say otherwise, of course).
I tried to keep these patches relatively simple/conservative to allow safe backporting to stable kernels that are affected by the regression.
The downstream port caps we should still check I suppose. Later versions of the spec extend the information for pretty much all port types. I started to write something similar [1] a while back, and by the looks of things I was probably basing that on the DP 1.2 spec since 1.3 has even more stuff there. Anyways we should put that logic into the DP helper so that other drivers migth use it as well.
[1] git://github.com/vsyrjala/linux.git dp_downstream_ports
Have to look at that. I don't have official access to the latest specs, just to whatever i could find floating in the internet.
thanks, -mario