It's not about whether it follows every line of the spec, but whether it makes sense to follow. But I'm not going to argue about this anymore, I've written enough to show what's the logical error, yet seems I am the only one in the world who sees a problem in switching color range according to resolution and refresh rate, which I don't see any hardware vendor would/should follow either. So if you don't see a problem here, do whatever you like. On 13 April 2015 at 22:22, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Mon, Apr 13, 2015 at 03:13:12PM +0100, Damien Lespiau wrote: >> On Wed, Apr 08, 2015 at 07:18:06PM +0800, Tom Yan wrote: >> > https://bugzilla.kernel.org/show_bug.cgi?id=94921 >> > >> > As mentioned in the above bug report, switching output color range >> > "Automatically" according to current mode does not make sense in >> > computer use case. >> >> Current code seems correct to me after re-reading CEA-861-E again. However can >> we do better? Maybe! From the spec: >> >> "The QS (AVI Q support) bit of byte 3 allows a display to declare that it >> supports the reception of either type of quantization range for any video >> format, under the direction of InfoFrame Q data (see Section 6.4 for >> information concerning bits Q1 and Q0). This allows a source to override the >> default quantization range for any video format. If the sink declares a >> selectable RGB Quantization Range (QS=1) then it shall expect limited range >> pixel values if it receives Q=1 and it shall expect full range pixel values if >> it receives Q=2 (see section 6.4). For other values of Q, the sink shall expect >> pixel values with the default range for the transmitted video format." >> >> So, for sinks that support it, we could default to sending the full >> range picture and overriding the quantization bit in the AVI infoframe. >> >> You could you try to run edid-decode [1] on your sink EDID to check if >> it supports overriding the quantization level (I added decoding the VCDB >> a while back). >> >> Ville, what do you think? > > Sure, if you can actually find a display that supports the Q bit. > I've not seen one yet :( They should have just made it mandatory, > otherwise I fear it's never going to catch on. > > -- > Ville Syrjälä > Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx