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.
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?
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
