[PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
Hans Verkuil
hverkuil at xs4all.nl
Fri Feb 2 03:20:21 PST 2024
On 02/02/2024 12:04, Jani Nikula wrote:
> On Mon, 15 Jan 2024, Sebastian Wick <sebastian.wick at redhat.com> wrote:
>> On Thu, Dec 07, 2023 at 04:49:31PM +0100, Maxime Ripard wrote:
>>> The i915 driver has a property to force the RGB range of an HDMI output.
>>> The vc4 driver then implemented the same property with the same
>>> semantics. KWin has support for it, and a PR for mutter is also there to
>>> support it.
>>>
>>> Both drivers implementing the same property with the same semantics,
>>> plus the userspace having support for it, is proof enough that it's
>>> pretty much a de-facto standard now and we can provide helpers for it.
>>>
>>> Let's plumb it into the newly created HDMI connector.
>>>
>>> Signed-off-by: Maxime Ripard <mripard at kernel.org>
>
> [snip]
>
>>> @@ -1655,6 +1678,26 @@ EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
>>> /**
>>> * DOC: HDMI connector properties
>>> *
>>> + * Broadcast RGB
>>> + * Indicates the RGB Quantization Range (Full vs Limited) used.
>>> + * Infoframes will be generated according to that value.
>>> + *
>>> + * The value of this property can be one of the following:
>>> + *
>>> + * Automatic:
>>> + * RGB Range is selected automatically based on the mode
>>> + * according to the HDMI specifications.
>>> + *
>>> + * Full:
>>> + * Full RGB Range is forced.
>>> + *
>>> + * Limited 16:235:
>>> + * Limited RGB Range is forced. Unlike the name suggests,
>>> + * this works for any number of bits-per-component.
>>> + *
>>> + * Drivers can set up this property by calling
>>> + * drm_connector_attach_broadcast_rgb_property().
>>> + *
>>
>> This is a good time to document this in more detail. There might be two
>> different things being affected:
>>
>> 1. The signalling (InfoFrame/SDP/...)
>> 2. The color pipeline processing
>>
>> All values of Broadcast RGB always affect the color pipeline processing
>> such that a full-range input to the CRTC is converted to either full- or
>> limited-range, depending on what the monitor is supposed to accept.
>>
>> When automatic is selected, does that mean that there is no signalling,
>> or that the signalling matches what the monitor is supposed to accept
>> according to the spec? Also, is this really HDMI specific?
>
> Automatic is based on the mode as described in the specs
> below. Basically certain modes are expected to be broadcast range, and
> others full range.
>
> I don't remember why we don't use the full range if the display
> indicates it supports selectable quantization range in Video
> Capabilities Data Block. It's quite possible there are displays that
> declare support but don't. Cc: Ville.
I have not seen such displays. Enabling RGB Selectable Quantization Range
is something that a vendor has to do explicitly, so it is reasonable to
expect that it works, otherwise there would be no point to that flag!
Transmitting full range if possible gives a better picture quality and
so is recommended.
>
> - HDMI 1.4b section 6.6 Video Quantization Ranges
>
> - HDMI 2.1 section 7.3 Video Quantization Ranges
>
> - DP 2.1 (and earlier) section 5.1.1.1 Video Colorimetry
>
> - CTA-861-H (and earlier) section 5.1 Default Encoding Parameters and
> section 6.4.3 Quantization Range
Note that CTA-861-H deprecated the use of Default Range in the AVI
InfoFrame, instead the source should always signal limited or full range
in the Q field.
Regards,
Hans
>
>> When full or limited is selected and the monitor doesn't support the
>> signalling, what happens?
>
> 1) Limited selected, display expects full, colors seem washed out.
>
> 2) Full selected, display expects limited, black screen possible.
>
> We receive the occasional bug report for 1, because there are displays
> that incorrectly expect full when spec says it should be limited. We
> reject the bug reports, because erring the other way can lead to black
> screens.
>
>
> BR,
> Jani.
>
>
>
More information about the Linux-rockchip
mailing list