On 02/02/2024 12:04, Jani Nikula wrote: > On Mon, 15 Jan 2024, Sebastian Wick <sebastian.wick@xxxxxxxxxx> 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@xxxxxxxxxx> > > [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. > > >
