All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Wentland <harry.wentland@amd.com>
To: <amd-gfx@lists.freedesktop.org>, <dri-devel@lists.freedesktop.org>
Cc: vprosyak@amd.com, ppaalanen@gmail.com,
	Uma Shankar <uma.shankar@intel.com>,
	sebastian.wick@redhat.com
Subject: [PATCH] drm: Don't block HDR_OUTPUT_METADATA on unknown EOTF
Date: Tue, 24 May 2022 14:33:20 -0400	[thread overview]
Message-ID: <20220524183320.28870-1-harry.wentland@amd.com> (raw)

The supported EOTFs are defined in eotf_supported in drm_edid
but userspace has no way of knowing what is and isn't supported
when creating an HDR_OUTPUT_METADATA and will only know
something is wrong when the atomic commit fails.

Since it is expected that userspace reads the EDID to understand
what the display supports it doesn't make sense for DRM to block
an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't
understand.

This comes with the added benefit of future-proofing metadata
support. If the spec defines a new EOTF there is no need to
update DRM and an compositor can immediately make use of it.

Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/609

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: ppaalanen@gmail.com
Cc: sebastian.wick@redhat.com
Cc: vprosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
---
 drivers/gpu/drm/drm_edid.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 12893e7be89b..223f96a72064 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5691,10 +5691,8 @@ drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
 
 	/* Sink EOTF is Bit map while infoframe is absolute values */
 	if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
-	    connector->hdr_sink_metadata.hdmi_type1.eotf)) {
-		DRM_DEBUG_KMS("EOTF Not Supported\n");
-		return -EINVAL;
-	}
+	    connector->hdr_sink_metadata.hdmi_type1.eotf))
+		DRM_DEBUG_KMS("Unknown EOTF %d\n", hdr_metadata->hdmi_metadata_type1.eotf);
 
 	err = hdmi_drm_infoframe_init(frame);
 	if (err < 0)
-- 
2.36.1


WARNING: multiple messages have this Message-ID (diff)
From: Harry Wentland <harry.wentland@amd.com>
To: <amd-gfx@lists.freedesktop.org>, <dri-devel@lists.freedesktop.org>
Cc: vprosyak@amd.com, ppaalanen@gmail.com,
	Uma Shankar <uma.shankar@intel.com>,
	Harry Wentland <harry.wentland@amd.com>,
	sebastian.wick@redhat.com
Subject: [PATCH] drm: Don't block HDR_OUTPUT_METADATA on unknown EOTF
Date: Tue, 24 May 2022 14:33:20 -0400	[thread overview]
Message-ID: <20220524183320.28870-1-harry.wentland@amd.com> (raw)

The supported EOTFs are defined in eotf_supported in drm_edid
but userspace has no way of knowing what is and isn't supported
when creating an HDR_OUTPUT_METADATA and will only know
something is wrong when the atomic commit fails.

Since it is expected that userspace reads the EDID to understand
what the display supports it doesn't make sense for DRM to block
an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't
understand.

This comes with the added benefit of future-proofing metadata
support. If the spec defines a new EOTF there is no need to
update DRM and an compositor can immediately make use of it.

Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/609

Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: ppaalanen@gmail.com
Cc: sebastian.wick@redhat.com
Cc: vprosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
---
 drivers/gpu/drm/drm_edid.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 12893e7be89b..223f96a72064 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5691,10 +5691,8 @@ drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
 
 	/* Sink EOTF is Bit map while infoframe is absolute values */
 	if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
-	    connector->hdr_sink_metadata.hdmi_type1.eotf)) {
-		DRM_DEBUG_KMS("EOTF Not Supported\n");
-		return -EINVAL;
-	}
+	    connector->hdr_sink_metadata.hdmi_type1.eotf))
+		DRM_DEBUG_KMS("Unknown EOTF %d\n", hdr_metadata->hdmi_metadata_type1.eotf);
 
 	err = hdmi_drm_infoframe_init(frame);
 	if (err < 0)
-- 
2.36.1


             reply	other threads:[~2022-05-24 18:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24 18:33 Harry Wentland [this message]
2022-05-24 18:33 ` [PATCH] drm: Don't block HDR_OUTPUT_METADATA on unknown EOTF Harry Wentland
2022-05-25  7:37 ` Pekka Paalanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220524183320.28870-1-harry.wentland@amd.com \
    --to=harry.wentland@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ppaalanen@gmail.com \
    --cc=sebastian.wick@redhat.com \
    --cc=uma.shankar@intel.com \
    --cc=vprosyak@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.