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