[PATCH] drm/edid: Add HDR Static Metadata Type 1 quirk for LG UltraGear

[PATCH] drm/edid: Add HDR Static Metadata Type 1 quirk for LG UltraGear

[Xela]

The LG UltraGear monitor (PNP ID GSM 0x7766) advertises HDR support in
its CTA-861 Extension block with SMPTE ST 2084 (PQ) EOTF support
(byte 0x9e = 0x05) and valid desired content luminance descriptors
(351 cd/m^2 max CLL/FALL at bytes 0xa0-0xa2).

However, due to a factory firmware bug, the HDR Static Metadata Data
Block descriptor byte (byte 0x9f) is reported as 0x00 instead of 0x01,
omitting the Static Metadata Type 1 capability bit (bit 0).

Because of this omitted bit, drm_parse_hdr_metadata_block() sets
metadata_type to 0. Consequently, drm_calculate_luminance_range()
rejects the block, and userspace attempts to perform atomic KMS commits
configuring HDR output metadata fail with -EINVAL (Error 22), preventing
compositors (Plasma, Gamescope, MPV) from engaging HDR on this display.

Introduce EDID_QUIRK_FORCE_HDR_STATIC_METADATA_TYPE1 to force the Static
Metadata Type 1 descriptor bit for displays with this defective EDID block,
and register the LG UltraGear (GSM 0x7766) in the EDID quirk table.

Signed-off-by: Xela <git@xela.zone>
---
 drivers/gpu/drm/drm_edid.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 07970e5b5..dd279fad1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -96,6 +96,8 @@ enum drm_edid_internal_quirk {
 	EDID_QUIRK_NON_DESKTOP,
 	/* Cap the DSC target bitrate to 15bpp */
 	EDID_QUIRK_CAP_DSC_15BPP,
+	/* Force Static Metadata Type 1 for HDR Static Metadata Data Block */
+	EDID_QUIRK_FORCE_HDR_STATIC_METADATA_TYPE1,
 };
 
 #define MICROSOFT_IEEE_OUI	0xca125c
@@ -195,6 +197,9 @@ static const struct edid_quirk {
 	/* LG 27GN950 */
 	EDID_QUIRK('G', 'S', 'M', 0x5b9a, BIT(EDID_QUIRK_CAP_DSC_15BPP)),
 
+	/* LG UltraGear (GSM 0x7766) */
+	EDID_QUIRK('G', 'S', 'M', 0x7766, BIT(EDID_QUIRK_FORCE_HDR_STATIC_METADATA_TYPE1)),
+
 	/* LGD panel of HP zBook 17 G2, eDP 10 bpc, but reports unknown bpc */
 	EDID_QUIRK('L', 'G', 'D', 764, BIT(EDID_QUIRK_FORCE_10BPC)),
 
@@ -5498,6 +5503,10 @@ drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
 	hdr_metadata->eotf = eotf_supported(db);
 	hdr_metadata->metadata_type = hdr_metadata_type(db);
 
+	if (drm_edid_has_internal_quirk(connector,
+				       EDID_QUIRK_FORCE_HDR_STATIC_METADATA_TYPE1))
+		hdr_metadata->metadata_type |= BIT(HDMI_STATIC_METADATA_TYPE1);
+
 	if (len >= 4)
 		hdr_metadata->max_cll = db[4];
 	if (len >= 5)
-- 
2.54.0

Re: [PATCH] drm/edid: Add HDR Static Metadata Type 1 quirk for LG UltraGear

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The calculation for minimum luminance in `drm_calculate_luminance_range` always evaluates to 0 due to flawed integer division.
- [High] `drm_calculate_luminance_range` incorrectly calculates the display's maximum luminance using the Max Frame-average Luminance field instead of the Max Luminance field.
--

--- Patch [1]: [PATCH] drm/edid: Add HDR Static Metadata Type 1 quirk for LG UltraGear ---
commit f96110d8b7a4665ac963f7b030033a65f6235f0a
Author: Xela <git@xela.zone>

drm/edid: Add HDR Static Metadata Type 1 quirk for LG UltraGear

The LG UltraGear monitor (PNP ID GSM 0x7766) advertises HDR support in
its CTA-861 Extension block with SMPTE ST 2084 (PQ) EOTF support
(byte 0x9e = 0x05) and valid desired content luminance descriptors
(351 cd/m^2 max CLL/FALL at bytes 0xa0-0xa2).

However, due to a factory firmware bug, the HDR Static Metadata Data
Block descriptor byte (byte 0x9f) is reported as 0x00 instead of 0x01,
omitting the Static Metadata Type 1 capability bit (bit 0).

Because of this omitted bit, drm_parse_hdr_metadata_block() sets
metadata_type to 0. Consequently, drm_calculate_luminance_range()
rejects the block, and userspace attempts to perform atomic KMS commits
configuring HDR output metadata fail with -EINVAL (Error 22), preventing
compositors (Plasma, Gamescope, MPV) from engaging HDR on this display.

Introduce EDID_QUIRK_FORCE_HDR_STATIC_METADATA_TYPE1 to force the Static
Metadata Type 1 descriptor bit for displays with this defective EDID block,
and register the LG UltraGear (GSM 0x7766) in the EDID quirk table.

> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 07970e5b5f65e..dd279fad17a42 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c

[ ... ]

> @@ -5498,6 +5503,10 @@ drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
>  	hdr_metadata->eotf = eotf_supported(db);
>  	hdr_metadata->metadata_type = hdr_metadata_type(db);
>  
> +	if (drm_edid_has_internal_quirk(connector,
> +				       EDID_QUIRK_FORCE_HDR_STATIC_METADATA_TYPE1))
> +		hdr_metadata->metadata_type |= BIT(HDMI_STATIC_METADATA_TYPE1);
> +
>  	if (len >= 4)
>  		hdr_metadata->max_cll = db[4];
>  	if (len >= 5)

[Severity: High]
This isn't a bug introduced by this patch, but there appears to be an issue
in how these values are used in drm_calculate_luminance_range() which is
called just after this block.

Does drm_calculate_luminance_range() incorrectly calculate max luminance
using the Max Frame-average Luminance field (max_fall) instead of the
Max Luminance field (max_cll)?

drivers/gpu/drm/drm_edid.c:drm_calculate_luminance_range() {
	...
	max_avg = hdr_metadata->max_fall;
	min_cll = hdr_metadata->min_cll;
	...
	q = max_avg >> 5;
	r = max_avg % 32;
	max = (1 << q) * pre_computed_values[r];
	...
}

It seems max_avg maps to max_fall, entirely ignoring hdr_metadata->max_cll.
Could this lead to underreporting the maximum peak luminance?

[Severity: High]
This is another pre-existing issue, but does the minimum luminance calculation
in drm_calculate_luminance_range() always evaluate to 0?

drivers/gpu/drm/drm_edid.c:drm_calculate_luminance_range() {
	...
	/* min luminance: maxLum * (CV/255)^2 / 100 */
	q = DIV_ROUND_CLOSEST(min_cll, 255);
	min = max * DIV_ROUND_CLOSEST((q * q), 100);
	...
}

Since min_cll is bounded to 255 (a 1-byte value), q will be at most 1, and
DIV_ROUND_CLOSEST(1, 100) truncates to 0. Would this force the computed
minimum luminance limit to always be exactly 0 for all panels? Can this
integer math sequence be adjusted to prevent the loss of precision?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260824040209.22517-1-git@xela.zone?part=1