EDID/DP color precision fixes on Intel hw for stable

[Mario Kleiner]

On 05/07/2016 08:15 PM, Ville Syrjälä wrote:
> 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.
>
>>

You are probably right. Rereading the bug report it seems to be a native 
DP panel without EDID color info, so the 6 bpc fallback only for native 
DP sinks should handle that.

I just sent out a new patch, also for stable, which folds the 6 bpc 
fallback into my DP bpc detection code.

I wonder if it would still make sense to apply the DFP 1.x bit handling 
in the shared EDID parser, just so we take full advantage of what info a 
EDID 1.3 provides? Although then we'd need a quirk for that panel again, 
as it does have a somewhat broken EDID.

thanks,
-mario

>> 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
>