[Intel-gfx] [PATCH] Remove illogical/bogus "Automatic" mode from "Broadcast RGB" property

[Tom Yan]

By the way it's extremely FORTUNATE that many vendors does not follow
this silly rule from CEA, because doing so means nothing else than
letting CEA to make certains mode "proprietary".

It is of course ideal to make devices support both range. But when the
cost is considered, the only sane compromise would be picking one
which is suitable for the targeted area (av playback only/general pc
usage), not to follow that stupid rule like making this support
limited range only:
http://www.eizoglobal.com/products/flexscan/ev2336w/index.html
and this support full range only:
http://www.eizoglobal.com/products/flexscan/ev2436w/index.html
while both is obviously PC monitors and belongs to the same series.
(Luckily in reality eizo DIDN'T follow that rule)

On 14 April 2015 at 19:18, Tom Yan <tom.ty89 at gmail.com> wrote:
> Are you sure it can only handle limited range in CEA modes and only
> full range in non CEA modes? Or is it the fact that it doesn't handle
> full range at all and its (or your) prefer mode happens to be a CEA
> mode? Or the whole series of this model only supports full range and
> the model you got happen to have a non CEA prefer mode, while the
> other model in the same series with CEA prefer mode would suffer
> anyway?
>
> Yes I can't tell how every vendor made their hardware, but it's silly
> for them to follow this spec and it's even sillier for you to make a
> driver specifically for those vendors. Because for example, if a user
> want to buy a monitor for photo editing, he must carefully avoid the
> ones with a prefer cea mode (or DP/HDMI ports). If one day cea declare
> that every mode "belongs to" them, the user will have nowhere to go.
>
> For a device with HDMI port, it might SEEM to work anyway because of
> convention. But for one with only DP (and DVI/VGA), which means it's
> literally a "pure PC monitor", I wonder how many of them have ANY
> support to limited range at all. (Neither should they, think about
> what a PC monitor is targeted at.)
>
> The EDID does have something can imply whether a device supports
> limited range, which is its capabilities of YCbCr color space(s),
> which are "inheritly" of limited range.
>
> P.S. In the case of NVIDIA blob, they locks the output range to
> limited if it reads the HDMI vendor number in the EDID (while a switch
> is available for VDPAU only which acts in a weird reverse way), while
> keeping DP untouched. This is not a very good reference but it seems
> necessary for the YCbCr output in their implementation, yet even this
> makes more sense to the mode/range mechanism.
>
> On 14 April 2015 at 16:38, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
>> On Tue, Apr 14, 2015 at 02:22:53PM +0800, Tom Yan wrote:
>>> 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.
>>
>> You assume no one follows the spec, but all I have to do is look at
>> the TV next to me and see that you're wrong.
>>
>> It's extremely unfortunate that displays can apparently get the
>> appropriate logo without following the spec. I can only conclude
>> that whatever conformance testing is done is insufficient.
>>
>> One option I was thinking would be to find some other hint in the
>> EDID that could tell us whether the device is likely to be spec
>> compliant, but sadly I've not found anything that would appear
>> to work.
>>
>>>
>>>
>>> On 13 April 2015 at 22:22, Ville Syrjälä <ville.syrjala at linux.intel.com> 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
>>
>> --
>> Ville Syrjälä
>> Intel OTC