From: Jani Nikula <jani.nikula@intel.com>
To: "Srinivas, Vidya" <vidya.srinivas@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Lee, Shawn C" <shawn.c.lee@intel.com>
Subject: RE: [PATCH] drm/displayid: reduce DisplayID checksum error logging to debug
Date: Tue, 24 Feb 2026 15:16:36 +0200 [thread overview]
Message-ID: <a709533a1f406109306ea9a46f2088d93ae8f53b@intel.com> (raw)
In-Reply-To: <PH7PR11MB8252364C58CFC0216A5FCC298977A@PH7PR11MB8252.namprd11.prod.outlook.com>
On Mon, 23 Feb 2026, "Srinivas, Vidya" <vidya.srinivas@intel.com> wrote:
>> -----Original Message-----
>> From: Nikula, Jani <jani.nikula@intel.com>
>> Sent: 23 February 2026 16:02
>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx@lists.freedesktop.org
>> Cc: intel-xe@lists.freedesktop.org; Srinivas, Vidya <vidya.srinivas@intel.com>
>> Subject: Re: [PATCH] drm/displayid: reduce DisplayID checksum error logging
>> to debug
>>
>> On Tue, 17 Feb 2026, Vidya Srinivas <vidya.srinivas@intel.com> wrote:
>> > The patch "drm/displayid: add quirk to ignore DisplayID checksum
>> > errors" introduced a mechanism to bypass checksum validation for
>> > certain panels. However, even when ignoring the error, the code
>> > continues to log a DRM_NOTE.
>>
>> Please refer to commits with the usual format (see git log).
>>
>> > On affected hardware, this results in persistent "DisplayID checksum
>> > invalid" messages in the system log. This noise often misleads users
>> > into thinking there is a critical hardware failure or a functional
>> > regression, despite the quirk successfully handling the issue.
>> >
>> > Downgrade the log level from DRM_NOTE to DRM_DEBUG_KMS. This keeps
>> the
>> > diagnostic information available for kernel developers while silencing
>> > the unnecessary warning for end-users.
>> >
>> > Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
>> > ---
>> > drivers/gpu/drm/drm_displayid.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_displayid.c
>> > b/drivers/gpu/drm/drm_displayid.c index 58d0bb6d2676..1f6d78fe29f2
>> > 100644
>> > --- a/drivers/gpu/drm/drm_displayid.c
>> > +++ b/drivers/gpu/drm/drm_displayid.c
>> > @@ -69,7 +69,7 @@ validate_displayid(const u8 *displayid, int length, int
>> idx, bool ignore_checksu
>> > for (i = 0; i < dispid_length; i++)
>> > csum += displayid[idx + i];
>> > if (csum) {
>> > - DRM_NOTE("DisplayID checksum invalid, remainder is
>> %d%s\n", csum,
>> > + DRM_DEBUG_KMS("DisplayID checksum invalid, remainder is
>> %d%s\n",
>> > +csum,
>> > ignore_checksum ? " (ignoring)" : "");
>>
>> I understand the desire to make it debug level with the quirk, but IMO it
>> needs to be more than debug level when there is no quirk.
>>
>> BR,
>> Jani.
>>
>
> Hello Jani
>
> Thank you so much. I understand your point.
> Only problem is other components not familiar with drm get confused about
> the message and say it is display issue. They also report this flooding
> is causing delay for their driver load etc.
It absolutely *is* a display issue, it's got a buggy EDID. It's not a
driver issue. If we go quiet about it, people will only notice the issue
through missing advanced display features as the DisplayID got skipped.
Like I said, make it debug level for displays that have the quirk
(ignore_checksum), and keep it noisier for displays that don't. If we
hit that, there's a (small) chance we can give the display vendor
feedback and have it fixed, otherwise we can add the quirk.
But the displays will never get fixed if we always keep quietly
accepting buggy EDIDs.
BR,
Jani.
>
> Regards
> Vidya
>
>>
>> >
>> > if (!ignore_checksum)
>>
>> --
>> Jani Nikula, Intel
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-02-24 13:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-17 5:50 [PATCH] drm/displayid: reduce DisplayID checksum error logging to debug Vidya Srinivas
2026-02-17 6:00 ` ✗ CI.checkpatch: warning for " Patchwork
2026-02-17 6:02 ` ✓ CI.KUnit: success " Patchwork
2026-02-17 6:36 ` ✓ Xe.CI.BAT: " Patchwork
2026-02-17 7:34 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-02-23 10:32 ` [PATCH] " Jani Nikula
2026-02-23 11:47 ` Srinivas, Vidya
2026-02-24 13:16 ` Jani Nikula [this message]
2026-02-24 14:40 ` Srinivas, Vidya
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=a709533a1f406109306ea9a46f2088d93ae8f53b@intel.com \
--to=jani.nikula@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=shawn.c.lee@intel.com \
--cc=vidya.srinivas@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox