From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Laurentiu Palcu <laurentiu.palcu@nxp.com>
Cc: Uma Shankar <uma.shankar@intel.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH] drm: fix HDR static metadata type field numbering
Date: Wed, 27 Nov 2019 17:17:03 +0200 [thread overview]
Message-ID: <20191127151703.GJ1208@intel.com> (raw)
In-Reply-To: <1574865719-24490-1-git-send-email-laurentiu.palcu@nxp.com>
On Wed, Nov 27, 2019 at 02:42:35PM +0000, Laurentiu Palcu wrote:
> According to CTA-861 specification, HDR static metadata data block allows a
> sink to indicate which HDR metadata types it supports by setting the SM_0 to
> SM_7 bits. Currently, only Static Metadata Type 1 is supported and this is
> indicated by setting the SM_0 bit to 1.
>
> However, the connector->hdr_sink_metadata.hdmi_type1.metadata_type is always
> 0, because hdr_metadata_type() in drm_edid.c checks the wrong bit.
>
> This patch corrects the HDMI_STATIC_METADATA_TYPE1 bit position.
Was confused for a while why this has even been workning, but I guess
that's due to userspace populating the metadata infoframe blob correctly
even if we misreported the metadata types in the parsed EDID metadata
blob.
Hmm. Actually on further inspection this all seems to be dead code. The
only thing we seem to use from the parsed EDID metadata stuff is
eotf bitmask. We check that in drm_hdmi_infoframe_set_hdr_metadata()
but we don't check the metadata type.
Maybe we should just nuke this EDID parsing stuff entirely? Seems
pretty much pointless.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
> ---
> include/linux/hdmi.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 9918a6c..216e25e 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -155,7 +155,7 @@ enum hdmi_content_type {
> };
>
> enum hdmi_metadata_type {
> - HDMI_STATIC_METADATA_TYPE1 = 1,
> + HDMI_STATIC_METADATA_TYPE1 = 0,
> };
>
> enum hdmi_eotf {
> --
> 2.7.4
--
Ville Syrjälä
Intel
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Laurentiu Palcu <laurentiu.palcu@nxp.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Uma Shankar <uma.shankar@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH] drm: fix HDR static metadata type field numbering
Date: Wed, 27 Nov 2019 17:17:03 +0200 [thread overview]
Message-ID: <20191127151703.GJ1208@intel.com> (raw)
Message-ID: <20191127151703.hZmnS3UnHTgceuQ4wGsGKZ2Y9OVoTjXSOUw99HX77bo@z> (raw)
In-Reply-To: <1574865719-24490-1-git-send-email-laurentiu.palcu@nxp.com>
On Wed, Nov 27, 2019 at 02:42:35PM +0000, Laurentiu Palcu wrote:
> According to CTA-861 specification, HDR static metadata data block allows a
> sink to indicate which HDR metadata types it supports by setting the SM_0 to
> SM_7 bits. Currently, only Static Metadata Type 1 is supported and this is
> indicated by setting the SM_0 bit to 1.
>
> However, the connector->hdr_sink_metadata.hdmi_type1.metadata_type is always
> 0, because hdr_metadata_type() in drm_edid.c checks the wrong bit.
>
> This patch corrects the HDMI_STATIC_METADATA_TYPE1 bit position.
Was confused for a while why this has even been workning, but I guess
that's due to userspace populating the metadata infoframe blob correctly
even if we misreported the metadata types in the parsed EDID metadata
blob.
Hmm. Actually on further inspection this all seems to be dead code. The
only thing we seem to use from the parsed EDID metadata stuff is
eotf bitmask. We check that in drm_hdmi_infoframe_set_hdr_metadata()
but we don't check the metadata type.
Maybe we should just nuke this EDID parsing stuff entirely? Seems
pretty much pointless.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
> ---
> include/linux/hdmi.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 9918a6c..216e25e 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -155,7 +155,7 @@ enum hdmi_content_type {
> };
>
> enum hdmi_metadata_type {
> - HDMI_STATIC_METADATA_TYPE1 = 1,
> + HDMI_STATIC_METADATA_TYPE1 = 0,
> };
>
> enum hdmi_eotf {
> --
> 2.7.4
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-11-27 15:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-27 14:42 [PATCH] drm: fix HDR static metadata type field numbering Laurentiu Palcu
2019-11-27 14:42 ` Laurentiu Palcu
2019-11-27 15:17 ` Ville Syrjälä [this message]
2019-11-27 15:17 ` Ville Syrjälä
2019-11-28 8:39 ` [EXT] " Laurentiu Palcu
2019-11-28 8:39 ` Laurentiu Palcu
2019-11-28 11:14 ` Ville Syrjälä
2019-11-28 11:14 ` Ville Syrjälä
2020-01-23 23:06 ` abhinavk
2020-01-23 23:06 ` abhinavk
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=20191127151703.GJ1208@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurentiu.palcu@nxp.com \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=uma.shankar@intel.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.