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