From: Jani Nikula <jani.nikula@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/edid: fix CEA extension byte #3 parsing
Date: Thu, 24 Mar 2022 11:58:17 +0200 [thread overview]
Message-ID: <87tubnhdty.fsf@intel.com> (raw)
In-Reply-To: <Yjs4E5gl3KZoUOBR@intel.com>
On Wed, 23 Mar 2022, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, Mar 23, 2022 at 12:04:38PM +0200, Jani Nikula wrote:
>> Only an EDID CEA extension has byte #3, while the CTA DisplayID Data
>> Block does not. Don't interpret bogus data for color formats.
>
> I think what we might want eventually is a cleaner split between
> the CTA data blocks vs. the rest of the EDID CTA ext block. Only
> the former is relevant for DisplayID.
>
> But for a bugfix we want to keep it simple.
>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Thanks, pushed to drm-misc-next-fixes.
BR,
Jani.
>
>>
>> For most displays it's probably an unlikely scenario you'd have a CTA
>> DisplayID Data Block without a CEA extension, but they do exist.
>>
>> Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID")
>> Cc: <stable@vger.kernel.org> # v4.15
>> Cc: Shawn C Lee <shawn.c.lee@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>
>> ---
>>
>> commit e28ad544f462 was merged in v5.3, but it has Cc: stable for v4.15.
>>
>> This is also fixed in my CEA data block iteration series [1], but we'll
>> want the simple fix for stable first.
>>
>> Hum, CTA is formerly CEA, I and the code seem to use both, should we use
>> only one or the other?
>
> And before CEA it was called EIA (IIRC). Dunno if we also use that name
> somewhere.
>
> If someone cares enough I guess we could rename everything to "cta".
>
>>
>> [1] https://patchwork.freedesktop.org/series/101659/
>> ---
>> drivers/gpu/drm/drm_edid.c | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 561f53831e29..ccf7031a6797 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -5187,10 +5187,14 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
>>
>> /* The existence of a CEA block should imply RGB support */
>> info->color_formats = DRM_COLOR_FORMAT_RGB444;
>> - if (edid_ext[3] & EDID_CEA_YCRCB444)
>> - info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
>> - if (edid_ext[3] & EDID_CEA_YCRCB422)
>> - info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
>> +
>> + /* CTA DisplayID Data Block does not have byte #3 */
>> + if (edid_ext[0] == CEA_EXT) {
>> + if (edid_ext[3] & EDID_CEA_YCRCB444)
>> + info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
>> + if (edid_ext[3] & EDID_CEA_YCRCB422)
>> + info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
>> + }
>>
>> if (cea_db_offsets(edid_ext, &start, &end))
>> return;
>> --
>> 2.30.2
--
Jani Nikula, Intel Open Source Graphics Center
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Shawn C Lee <shawn.c.lee@intel.com>,
stable@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/edid: fix CEA extension byte #3 parsing
Date: Thu, 24 Mar 2022 11:58:17 +0200 [thread overview]
Message-ID: <87tubnhdty.fsf@intel.com> (raw)
In-Reply-To: <Yjs4E5gl3KZoUOBR@intel.com>
On Wed, 23 Mar 2022, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, Mar 23, 2022 at 12:04:38PM +0200, Jani Nikula wrote:
>> Only an EDID CEA extension has byte #3, while the CTA DisplayID Data
>> Block does not. Don't interpret bogus data for color formats.
>
> I think what we might want eventually is a cleaner split between
> the CTA data blocks vs. the rest of the EDID CTA ext block. Only
> the former is relevant for DisplayID.
>
> But for a bugfix we want to keep it simple.
>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Thanks, pushed to drm-misc-next-fixes.
BR,
Jani.
>
>>
>> For most displays it's probably an unlikely scenario you'd have a CTA
>> DisplayID Data Block without a CEA extension, but they do exist.
>>
>> Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID")
>> Cc: <stable@vger.kernel.org> # v4.15
>> Cc: Shawn C Lee <shawn.c.lee@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>
>> ---
>>
>> commit e28ad544f462 was merged in v5.3, but it has Cc: stable for v4.15.
>>
>> This is also fixed in my CEA data block iteration series [1], but we'll
>> want the simple fix for stable first.
>>
>> Hum, CTA is formerly CEA, I and the code seem to use both, should we use
>> only one or the other?
>
> And before CEA it was called EIA (IIRC). Dunno if we also use that name
> somewhere.
>
> If someone cares enough I guess we could rename everything to "cta".
>
>>
>> [1] https://patchwork.freedesktop.org/series/101659/
>> ---
>> drivers/gpu/drm/drm_edid.c | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 561f53831e29..ccf7031a6797 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -5187,10 +5187,14 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
>>
>> /* The existence of a CEA block should imply RGB support */
>> info->color_formats = DRM_COLOR_FORMAT_RGB444;
>> - if (edid_ext[3] & EDID_CEA_YCRCB444)
>> - info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
>> - if (edid_ext[3] & EDID_CEA_YCRCB422)
>> - info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
>> +
>> + /* CTA DisplayID Data Block does not have byte #3 */
>> + if (edid_ext[0] == CEA_EXT) {
>> + if (edid_ext[3] & EDID_CEA_YCRCB444)
>> + info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
>> + if (edid_ext[3] & EDID_CEA_YCRCB422)
>> + info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
>> + }
>>
>> if (cea_db_offsets(edid_ext, &start, &end))
>> return;
>> --
>> 2.30.2
--
Jani Nikula, Intel Open Source Graphics Center
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
stable@vger.kernel.org, Shawn C Lee <shawn.c.lee@intel.com>
Subject: Re: [PATCH] drm/edid: fix CEA extension byte #3 parsing
Date: Thu, 24 Mar 2022 11:58:17 +0200 [thread overview]
Message-ID: <87tubnhdty.fsf@intel.com> (raw)
In-Reply-To: <Yjs4E5gl3KZoUOBR@intel.com>
On Wed, 23 Mar 2022, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, Mar 23, 2022 at 12:04:38PM +0200, Jani Nikula wrote:
>> Only an EDID CEA extension has byte #3, while the CTA DisplayID Data
>> Block does not. Don't interpret bogus data for color formats.
>
> I think what we might want eventually is a cleaner split between
> the CTA data blocks vs. the rest of the EDID CTA ext block. Only
> the former is relevant for DisplayID.
>
> But for a bugfix we want to keep it simple.
>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Thanks, pushed to drm-misc-next-fixes.
BR,
Jani.
>
>>
>> For most displays it's probably an unlikely scenario you'd have a CTA
>> DisplayID Data Block without a CEA extension, but they do exist.
>>
>> Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID")
>> Cc: <stable@vger.kernel.org> # v4.15
>> Cc: Shawn C Lee <shawn.c.lee@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>
>> ---
>>
>> commit e28ad544f462 was merged in v5.3, but it has Cc: stable for v4.15.
>>
>> This is also fixed in my CEA data block iteration series [1], but we'll
>> want the simple fix for stable first.
>>
>> Hum, CTA is formerly CEA, I and the code seem to use both, should we use
>> only one or the other?
>
> And before CEA it was called EIA (IIRC). Dunno if we also use that name
> somewhere.
>
> If someone cares enough I guess we could rename everything to "cta".
>
>>
>> [1] https://patchwork.freedesktop.org/series/101659/
>> ---
>> drivers/gpu/drm/drm_edid.c | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 561f53831e29..ccf7031a6797 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -5187,10 +5187,14 @@ static void drm_parse_cea_ext(struct drm_connector *connector,
>>
>> /* The existence of a CEA block should imply RGB support */
>> info->color_formats = DRM_COLOR_FORMAT_RGB444;
>> - if (edid_ext[3] & EDID_CEA_YCRCB444)
>> - info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
>> - if (edid_ext[3] & EDID_CEA_YCRCB422)
>> - info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
>> +
>> + /* CTA DisplayID Data Block does not have byte #3 */
>> + if (edid_ext[0] == CEA_EXT) {
>> + if (edid_ext[3] & EDID_CEA_YCRCB444)
>> + info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
>> + if (edid_ext[3] & EDID_CEA_YCRCB422)
>> + info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
>> + }
>>
>> if (cea_db_offsets(edid_ext, &start, &end))
>> return;
>> --
>> 2.30.2
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2022-03-24 9:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-23 10:04 [Intel-gfx] [PATCH] drm/edid: fix CEA extension byte #3 parsing Jani Nikula
2022-03-23 10:04 ` Jani Nikula
2022-03-23 10:04 ` Jani Nikula
2022-03-23 12:28 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for " Patchwork
2022-03-23 12:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-23 15:09 ` [Intel-gfx] [PATCH] " Ville Syrjälä
2022-03-23 15:09 ` Ville Syrjälä
2022-03-23 15:09 ` Ville Syrjälä
2022-03-23 15:19 ` [Intel-gfx] " Jani Nikula
2022-03-23 15:19 ` Jani Nikula
2022-03-23 15:19 ` Jani Nikula
2022-03-24 9:58 ` Jani Nikula [this message]
2022-03-24 9:58 ` Jani Nikula
2022-03-24 9:58 ` Jani Nikula
2022-03-23 15:57 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
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=87tubnhdty.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.org \
--cc=ville.syrjala@linux.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.