<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - [SNB] Full/Limited Color range not working automatically for 1000/1001 CEA modes" href="https://bugs.freedesktop.org/show_bug.cgi?id=46800#c23">Comment # 23</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - [SNB] Full/Limited Color range not working automatically for 1000/1001 CEA modes" href="https://bugs.freedesktop.org/show_bug.cgi?id=46800">bug 46800</a> from <a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> Ville Syrjala</a> <pre>(In reply to <a href="show_bug.cgi?id=46800#c21">comment #21</a>) > The quantization range signaling doesn't seem to be working on Haswell. > > I am outputting from a D54250WYK NUC to Pioneer KRP-500m (via Yamaha > RX-A1000) and seeing grey blacks with the default limited RGB range. When I > switch to full range using xrandr, picture is fine. I assume my monitor > supports switching RGB range automatically as my bluray player is able to > signal it (switch player output RGB range between full and limited, > displayed black levels do not change; I can verify that the output range > really changes by setting input range manually in the Pioneer). Hmm. We're supposed to be sending the quantization range in the infoframe iff the sink says it supports quantization range selection. To verify boot /w drm.debug=6 and look for "CEA VCDB ..." in the log. Or just attach the EDID here, and I can double check whether we're decoding it correctly. But note that we support RGB output only, whereas your bluray player could be outputting YCbCr, which has its own quantization range selection. In theory I think we should default to YCbCr for CEA formats when the sink supports it. But that still doesn't excuse the sink for not respecting the spec wrt. the RGB quantization range rules. I can only assume that the compliance tests (if there are any, I don't know) don't check for this case since there appear to a significant number of monitors that fail this. > > There are more people in the xbmc forum nuc thread (see for example starting > at <a href="http://forum.xbmc.org/showthread.php?tid=176718&pid=1548847#pid1548847">http://forum.xbmc.org/showthread.php?tid=176718&pid=1548847#pid1548847</a>) > reporting grey blacks with the default setting, so it's probably not just my > system. Based on > <a href="http://forum.xbmc.org/showthread.php?tid=176718&pid=1552262#pid1552262">http://forum.xbmc.org/showthread.php?tid=176718&pid=1552262#pid1552262</a> (and > the few comments following), same issue may be present on earlier chipsets > too. > > Unfortunately I don't have access to an HDMI analyzer. Is there any other > way I could supply useful data? > > > For best quality it would be nice to have full range output, but have the > ability to signal limited range if desired. This would preserve > blacker-than-black, whiter-than-white and avoid banding from luma range > expansion. We're trying to do it according to spec. Limited range for CEA video formats except 640x480, and full range for the rest. If we would default to full range, we'd cause problems for spec compliant monitors that don't implement the quantization range selection infoframe knob. That's assuming there are enough spec compliant monitors out there to justify it. If there are a lot more non-compliant monitors, then I guess we should rethink this decision. Unfortunately I have no way of knowing what the ratio of bad vs. good monitors is.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>