All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "jpeisach@ubuntu.com" <jpeisach@ubuntu.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/edid: Use struct cea_db when parsing HDMI VSDB
Date: Tue, 20 Jan 2026 19:03:51 +0200	[thread overview]
Message-ID: <aW-1d--9syo7F61k@intel.com> (raw)
In-Reply-To: <E4531EA5-EF45-493F-A1EB-7677D0BC71FC@ubuntu.com>

On Tue, Jan 20, 2026 at 11:37:59AM -0500, jpeisach@ubuntu.com wrote:
> 
> 
> > On Jan 20, 2026, at 10:41 AM, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > 
> > On Mon, Jan 19, 2026 at 03:39:12PM +0200, Jani Nikula wrote:
> >> On Sat, 17 Jan 2026, Joshua Peisach <jpeisach@ubuntu.com> wrote:
> >>> drm_parse_hdmi_vsdb_video is one of the parsers that still do not use the
> >>> cea_db struct, and currently passes a u8 pointer.
> >>> 
> >>> Set the correct struct type and update references to the data accordingly.
> >>> This also makes the same change to drm_parse_hdmi_deep_color_info as
> >>> necessary.
> >>> 
> >>> Signed-off-by: Joshua Peisach <jpeisach@ubuntu.com>
> >>> ---
> >>> drivers/gpu/drm/drm_edid.c | 26 +++++++++++++-------------
> >>> 1 file changed, 13 insertions(+), 13 deletions(-)
> >>> 
> >>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >>> index 26bb7710a..15bd99e65 100644
> >>> --- a/drivers/gpu/drm/drm_edid.c
> >>> +++ b/drivers/gpu/drm/drm_edid.c
> >>> @@ -6290,7 +6290,7 @@ static void drm_parse_hdmi_forum_scds(struct drm_connector *connector,
> >>> }
> >>> 
> >>> static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> >>> -					   const u8 *hdmi)
> >>> +					   const struct cea_db *db)
> >>> {
> >>> 	struct drm_display_info *info = &connector->display_info;
> >>> 	unsigned int dc_bpc = 0;
> >>> @@ -6298,24 +6298,24 @@ static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> >>> 	/* HDMI supports at least 8 bpc */
> >>> 	info->bpc = 8;
> >>> 
> >>> -	if (cea_db_payload_len(hdmi) < 6)
> >>> +	if (cea_db_payload_len(db) < 6)
> >>> 		return;
> >>> 
> >>> -	if (hdmi[6] & DRM_EDID_HDMI_DC_30) {
> >>> +	if (db->data[6] & DRM_EDID_HDMI_DC_30) {
> >> 
> >> That's not the same thing, but off-by-one now. Ditto everywhere that
> >> changes from u8* to db->data[].
> >> 
> >> The main problem with the change (even with fixed offsets) is that the
> >> *specs* typically use indexing from the beginning of the data block, not
> >> from the beginning of payload data.
> >> 
> >> We've discussed this before with Ville (Cc'd) but I'm not sure if we
> >> reached a conclusion.
> > 
> > I guess we could give up on the index matching the spec byte#.
> > Looks like the HDMI VSDB parsing is the only place where we
> > actually have the two match, and everwhere else it's
> > already inconsistent.
> > 
> > Also maybe we should add something to also exclude the
> > extended tag from the payload, for the blocks that use
> > the extended tag...
> > 
> > -- 
> > Ville Syrjälä
> > Intel
> 
> I personally believe it is important to match the spec for consistency
> and reference. Unless I am looking at the wrong thing, bit 6 should have
> the correct index.
> 
> Also I think cea_db in the context of the function calls here are
> just the data blocks. Unless you mean that by having the struct's first
> member being the tag_length if offsetting everything, but I don't think
> it is? Let me know if I'm wrong :)

The tag+length byte is:
byte# 1 in the CTA spec
byte# 0 in the HDMI spec

There's no super nice way to use the byte# as the index for both.
Also the length checks end up looking somewhat confusing when
comparing them with the corresponding index.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2026-01-20 17:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-17 20:51 [PATCH] drm/edid: Use struct cea_db when parsing HDMI VSDB Joshua Peisach
2026-01-19 13:39 ` Jani Nikula
2026-01-19 22:44   ` jpeisach
2026-01-20 15:41   ` Ville Syrjälä
2026-01-20 16:37     ` jpeisach
2026-01-20 17:03       ` Ville Syrjälä [this message]
2026-01-20 17:46         ` jpeisach
2026-01-20 18:09           ` Ville Syrjälä
2026-01-20 20:01             ` jpeisach
2026-01-20 20:39               ` Ville Syrjälä
2026-01-22  1:25                 ` Joshua Peisach

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=aW-1d--9syo7F61k@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jpeisach@ubuntu.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.