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

[Tom Yan]

I feel silly that I write another mail about this, but I really want
who ever read this mail list would have a chance to at least think
about why does the CEA modes->limited range mechanism ever exist and
where should it (not) apply.

For those who feel thrown away from his comfort zone when told a spec
is non-sense. (Yes, it probably make sense SOMEwhere)

First, what are CEA modes? Why are certain modes considered special by
the Consumer Electronic Association? Compare the two lists and you
should understand:

http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_edid.c#L606
http://en.wikipedia.org/wiki/Blu-ray_Disc#Video

Yes, these modes are standard in video discs like Blu-ray or DVD (or
TV broadcasting).

"Okay, so why the spec said these mode should be use with limited color range?"

There's another reason I compare the mode list with the table in the
wiki's section of "Blu-ray Video" -- because video discs / files are
encoded in limited color range. (Google the reason yourself :P)

"Then why didn't the spec require limited color range to be used for
every possible modes exists in the world?"

A possbile reason is, they want to make sure av products (i think tv,
a sink, might be the only possible case) have a rule to follow if the
vendor want it to support both full and limited range but without
introducing a setting that requires the user to understand this whole
thing.

That might be the reason why someone claim that their device follow
this rule. Yes it might be true, because the vendors (of a TV) might
want to give their user "best user experience" by keeping their user
ignorant, at the same time stopping user who need full range with CEA
modes to pick it himself. (Time to think: should we follow these
vendors then?) So even if the hardware support both range, there is no
option to change manually.

But the thing is this rule PRIORITIZE video disc/file playback (assume
it is the case whenever the source is in CEA modes, hence use limited
color range), and use full range for other case (because limited range
is rarely used/necessary/appropriate for other cases).

"So what's the problem if we write a graphic card driver following
this rule for HDMI and DP?"

By following this rule, it means the graphic card (pc) is PRIORITZED
to video disc/file playback, while leaving other jobs as second-class
citizens. Remember, your PC is not a Blu-ray Player even if you mainly
use it for video playback, not everyone use it like this.

Worsestill, video playback software might not actually deal with
limited range output appropriately because they might have assume PC
monitor supports full range only. So even if your monitor or TV
support it, you might still experience a Limited(Source
File)->Full(Interpolated by the player)->Limited(Compressed again by
the gfx driver) conversion.

For the case of HDMI, at least for the "TVs", following the rule might
not cause a problem because they are mostly expected to deal with
source like Blu-ray/DVD players, which is totally acceptable if they
could only output limited range. The only weakness would be making you
to "suffer" the lossy-compressed limited color range.

But if some HDMI "PC monitors" does not assume it should be used with
source the those players, they might fail to support limited range.
Yet I wouldn't call this a problem of them because if it's made as a
PC monitor, it's fine that they support only full range, which is used
for general purpose.

The worst case is to follow the rule with DisplayPort.

Sorry I can't help this time. I can only say that VESA is stupid, or
actually greedy to adopt this rule.

The only reason I can think of for them to follow this rule is, at the
beginning (or still) they think that DisplayPort is gonna replace HDMI
and be the only connector in the PC and AV worlds, so they try to have
as many as possible the same "basic properties" as HDMI, so that not
to upset any AV product vendors.

But the thing is, nobody shows VESA a damn about this.

If you see a Blu-ray Player, or even a TV with DisplayPort, don't
forget to take a picture (and send me please I beg you).

And in the PC world, no body wants limited range when you do photo
editing, gaming or even web browsing and coding. Why? It's simple
substraction.

So in the end, with the help of some graphic card vendors, you and I
are successfully pissed by VESA's greed if we got a DP monitor which
happen have a CEA prefer mode.

On 14 April 2015 at 19:35, Tom Yan <tom.ty89 at gmail.com> wrote:
> 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