drm/edid: Add kernel parameter for override edid check

drm/edid: Add kernel parameter for override edid check

[Christoph Thielecke]

[-- Attachment #1.1: Type: text/plain, Size: 3745 bytes --]

Hello all,


I run in the same problem as lot of other people since a longer time.
The edid reported by my external monitor is no longer accepted and only resolutions up to 
1024x768 are possible (supported by hardware: 1920x1200).
It seems the kernel drm module gained a strict check of the edid delived by the monitor.


The kernel logs shows:
[    7.172357] [drm] Initialized nouveau 1.4.0 for 0000:01:00.0 on minor 0
[    7.356212] EDID block 0 (tag 0x00) checksum is invalid, remainder is 210
[    7.356220]     [00] BAD  00 ff ff ff ff ff ff 00 a1 ff a0 46 a1 ff a0 4a
[    7.356221]     [00] BAD  d0 ff 01 50 ff ff 20 78 2a 5a d5 a7 56 4b 9b 24
[    7.356222]     [00] BAD  13 50 54 ff 08 00 81 00 81 80 95 00 a9 40 b3 00
[    7.356223]     [00] BAD  8b c0 d0 9b a1 ff a0 9c a1 ff a0 9d a1 ff a0 9e
[    7.356224]     [00] BAD  a1 ff a0 ff ff ff a0 ac a1 ff a0 ad a1 ff a1 ff
[    7.356225]     [00] BAD  50 ff ff 9e a1 ff a0 9f a1 ff a0 a0 a1 ff a0 a1
[    7.356226]     [00] BAD  d0 ff a0 ff a0 ae b0 ff d0 ff ff ff d0 ff ff ff
[    7.356227]     [00] BAD  a0 ad a1 d0 ff ff 20 50 ff 20 20 50 ff ff 50 ff
[    7.356232] nouveau 0000:01:00.0: drm: DDC responded, but no EDID for VGA-1


(the monitor is a 24” Yuraku MB24WKH, product number: Yur.Vision YV24WBH1)


After seaching the net, I found that a lot of people have this problem.


It would be nice to have a new kernel parameter of the drm module as proposed by Alex 
called "edid_strict" (https://lists.freedesktop.org/archives/dri-devel/2011-January/
006778.html[1]). Set the param to “0” will disable the check and let accept the edid 
reported by the monitor.


The only workaround to get the higher resolution working is to provide a edid firmware 
file using the parameter “edid_firmware”. This needs to be created manually and build into 
the initrd to be available early at runtime.
I think the workaround isn’t very user friendly.
Putting a flag to disable the edid strict check would help more people get their moditors 
more easy runnning by their own responsibilty.


At a later time I think a solution for controlling the edid check at runtime should be made 
possible, so that desktop environmens like KDE can implement an manually override by 
specifying a firmware file or disable the the edid check.
 


References:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/712075[2]
https://lists.freedesktop.org/archives/dri-devel/2011-January/006778.html[1]


Monitor edid:
monitor-get-edid | hexdump  
0000000 ff00 ffff ffff 00ff e430 025a 0000 0000 
0000010 1300 0401 2595 7817 4402 9c75 5459 2796 
0000020 5023 0054 0000 0101 0101 0101 0101 0101 
0000030 0101 0101 0101 37c8 6480 b070 400f 2022 
0000040 0036 e672 0010 1a00 283c a080 b070 4023 
0000050 2030 0036 e672 0010 1a00 0000 fe00 4800 
0000060 3830 5236 3182 3137 5557 0a37 0000 0000 
0000070 0000 3141 001e 0000 0600 0a01 2020 2300 
0000080 

monitor-get-edid | monitor-parse-edid 
EISA ID: LGD025a 
EDID version: 1.4 
EDID extension blocks: 0 
Screen size: 37.0 cm x 23.0 cm (17.15 inches, aspect ratio 16/10 = 1.61) 
Gamma: 2.2 
Digital signal 

       # Monitor preferred modeline (58.2 Hz vsync, 70.7 kHz hsync, ratio 16/10, 131 dpi) 
       ModeLine "1920x1200" 142.8 1920 1954 1986 2020 1200 1203 1209 1215 -hsync 
+vsync 

       # Monitor supported modeline (40.1 Hz vsync, 49.5 kHz hsync, ratio 16/10, 131 dpi) 
       ModeLine "1920x1200" 103 1920 1968 2000 2080 1200 1203 1209 1235 -hsync +vsync



With best regards


Christoph
--



--------
[1] https://lists.freedesktop.org/archives/dri-devel/2011-January/006778.html
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/712075

[-- Attachment #1.2: Type: text/html, Size: 9393 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: drm/edid: Add kernel parameter for override edid check

[Jani Nikula]

On Mon, 03 Nov 2025, Christoph Thielecke <christoph.thielecke@gmx.de> wrote:
> Hello all,
>
>
> I run in the same problem as lot of other people since a longer time.
> The edid reported by my external monitor is no longer accepted and only resolutions up to 
> 1024x768 are possible (supported by hardware: 1920x1200).
> It seems the kernel drm module gained a strict check of the edid delived by the monitor.

Seems like you're referring to something that happened 15+ years
ago. It's not like it's a recent regression, is it?

> The kernel logs shows:
> [    7.172357] [drm] Initialized nouveau 1.4.0 for 0000:01:00.0 on minor 0
> [    7.356212] EDID block 0 (tag 0x00) checksum is invalid, remainder is 210
> [    7.356220]     [00] BAD  00 ff ff ff ff ff ff 00 a1 ff a0 46 a1 ff a0 4a
> [    7.356221]     [00] BAD  d0 ff 01 50 ff ff 20 78 2a 5a d5 a7 56 4b 9b 24
> [    7.356222]     [00] BAD  13 50 54 ff 08 00 81 00 81 80 95 00 a9 40 b3 00
> [    7.356223]     [00] BAD  8b c0 d0 9b a1 ff a0 9c a1 ff a0 9d a1 ff a0 9e
> [    7.356224]     [00] BAD  a1 ff a0 ff ff ff a0 ac a1 ff a0 ad a1 ff a1 ff
> [    7.356225]     [00] BAD  50 ff ff 9e a1 ff a0 9f a1 ff a0 a0 a1 ff a0 a1
> [    7.356226]     [00] BAD  d0 ff a0 ff a0 ae b0 ff d0 ff ff ff d0 ff ff ff
> [    7.356227]     [00] BAD  a0 ad a1 d0 ff ff 20 50 ff 20 20 50 ff ff 50 ff

Simply ignoring the invalid checksum on this EDID will lead to other
problems. The EDID claims to have 0x50 extension blocks. That's bogus,
as normally you have 0-3. There are limits to how much garbage you can
accept and pretend it's all fine.

> [    7.356232] nouveau 0000:01:00.0: drm: DDC responded, but no EDID for VGA-1
>
>
> (the monitor is a 24” Yuraku MB24WKH, product number: Yur.Vision YV24WBH1)
>
>
> After seaching the net, I found that a lot of people have this problem.
>
>
> It would be nice to have a new kernel parameter of the drm module as proposed by Alex 
> called "edid_strict" (https://lists.freedesktop.org/archives/dri-devel/2011-January/
> 006778.html[1]). Set the param to “0” will disable the check and let accept the edid 
> reported by the monitor.

That suggestion too is very old. I think over the years the mentality
towards module parameters has changed considerably. Requiring users to
set a module parameter is not a fix.

> The only workaround to get the higher resolution working is to provide a edid firmware 
> file using the parameter “edid_firmware”. This needs to be created manually and build into 
> the initrd to be available early at runtime.
> I think the workaround isn’t very user friendly.
> Putting a flag to disable the edid strict check would help more people get their moditors 
> more easy runnning by their own responsibilty.
>
>
> At a later time I think a solution for controlling the edid check at runtime should be made 
> possible, so that desktop environmens like KDE can implement an manually override by 
> specifying a firmware file or disable the the edid check.

I think generally the solution would be a quirk, but we don't really
have a mechanism to identify displays based on half-read EDIDs. Chicken
and egg.

And then there's the problem that it's not just the checksum that
appears to be wrong here. The workaround pretty much is the edid
firmware option.

> References:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/712075[2]
> https://lists.freedesktop.org/archives/dri-devel/2011-January/006778.html[1]
>
>
> Monitor edid:
> monitor-get-edid | hexdump  
> 0000000 ff00 ffff ffff 00ff e430 025a 0000 0000 
> 0000010 1300 0401 2595 7817 4402 9c75 5459 2796 
> 0000020 5023 0054 0000 0101 0101 0101 0101 0101 
> 0000030 0101 0101 0101 37c8 6480 b070 400f 2022 
> 0000040 0036 e672 0010 1a00 283c a080 b070 4023 
> 0000050 2030 0036 e672 0010 1a00 0000 fe00 4800 
> 0000060 3830 5236 3182 3137 5557 0a37 0000 0000 
> 0000070 0000 3141 001e 0000 0600 0a01 2020 2300 
> 0000080 

This is not the same EDID as you list above. This one actually has the
correct checksum. I don't know monitor-get-edid nor monitor-parse-edid,
where are they from?


BR,
Jani.

>
> monitor-get-edid | monitor-parse-edid 
> EISA ID: LGD025a 
> EDID version: 1.4 
> EDID extension blocks: 0 
> Screen size: 37.0 cm x 23.0 cm (17.15 inches, aspect ratio 16/10 = 1.61) 
> Gamma: 2.2 
> Digital signal 
>
>        # Monitor preferred modeline (58.2 Hz vsync, 70.7 kHz hsync, ratio 16/10, 131 dpi) 
>        ModeLine "1920x1200" 142.8 1920 1954 1986 2020 1200 1203 1209 1215 -hsync 
> +vsync 
>
>        # Monitor supported modeline (40.1 Hz vsync, 49.5 kHz hsync, ratio 16/10, 131 dpi) 
>        ModeLine "1920x1200" 103 1920 1968 2000 2080 1200 1203 1209 1235 -hsync +vsync
>
>
>
> With best regards
>
>
> Christoph
> --
>
>
>
> --------
> [1] https://lists.freedesktop.org/archives/dri-devel/2011-January/006778.html
> [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/712075

-- 
Jani Nikula, Intel

Re: drm/edid: Add kernel parameter for override edid check

[Christoph Thielecke]

[-- Attachment #1.1: Type: text/plain, Size: 4847 bytes --]

Hello Jani,

thanks for the quick answer.



> > I run in the same problem as lot of other people since a longer time.
> > The edid reported by my external monitor is no longer accepted and only
> > resolutions up to 1024x768 are possible (supported by hardware:
> > 1920x1200).
> > It seems the kernel drm module gained a strict check of the edid delived
> > by the monitor.
> Seems like you're referring to something that happened 15+ years
> ago. It's not like it's a recent regression, is it?

It happing to me some years ago (but less than 3 I think), it’s not a recent regression 
(you’re right).
The interesting thing is that it worked fine and then it stopped working after a update.

 
> > The kernel logs shows:
> > [    7.172357] [drm] Initialized nouveau 1.4.0 for 0000:01:00.0 on minor 0
> > [    7.356212] EDID block 0 (tag 0x00) checksum is invalid, remainder is
> > 210 [    7.356220]     [00] BAD  00 ff ff ff ff ff ff 00 a1 ff a0 46 a1
> > ff a0 4a [    7.356221]     [00] BAD  d0 ff 01 50 ff ff 20 78 2a 5a d5 a7
> > 56 4b 9b 24 [    7.356222]     [00] BAD  13 50 54 ff 08 00 81 00 81 80 95
> > 00 a9 40 b3 00 [    7.356223]     [00] BAD  8b c0 d0 9b a1 ff a0 9c a1 ff
> > a0 9d a1 ff a0 9e [    7.356224]     [00] BAD  a1 ff a0 ff ff ff a0 ac a1
> > ff a0 ad a1 ff a1 ff [    7.356225]     [00] BAD  50 ff ff 9e a1 ff a0 9f
> > a1 ff a0 a0 a1 ff a0 a1 [    7.356226]     [00] BAD  d0 ff a0 ff a0 ae b0
> > ff d0 ff ff ff d0 ff ff ff [    7.356227]     [00] BAD  a0 ad a1 d0 ff ff
> > 20 50 ff 20 20 50 ff ff 50 ff
> Simply ignoring the invalid checksum on this EDID will lead to other
> problems. The EDID claims to have 0x50 extension blocks. That's bogus,
> as normally you have 0-3. There are limits to how much garbage you can
> accept and pretend it's all fine.

Hm, thats strange.


> > [    7.356232] nouveau 0000:01:00.0: drm: DDC responded, but no EDID for
> > VGA-1
> > 
> > 
> > (the monitor is a 24” Yuraku MB24WKH, product number: Yur.Vision YV24WBH1)
> > 
> > 
> > After seaching the net, I found that a lot of people have this problem.
> > 
> > 
> > It would be nice to have a new kernel parameter of the drm module as
> > proposed by Alex called "edid_strict"
> > (https://lists.freedesktop.org/archives/dri-devel/2011-January/
> > 006778.html[1]). Set the param to “0” will disable the check and let
> > accept the edid reported by the monitor.
> 
> That suggestion too is very old. I think over the years the mentality
> towards module parameters has changed considerably. Requiring users to
> set a module parameter is not a fix.

I know it's an old idea. But unlikely without a module parameter the only way to get a 
higher resolution than 1024x768 is to provide a generated edid bin file at initrd time, 
which is much harder to get in place.


> > The only workaround to get the higher resolution working is to provide a
> > edid firmware file using the parameter “edid_firmware”. This needs to be
> > created manually and build into the initrd to be available early at
> > runtime.
> > I think the workaround isn’t very user friendly.
> > Putting a flag to disable the edid strict check would help more people get
> > their moditors more easy runnning by their own responsibilty.
> > 
> > 
> > At a later time I think a solution for controlling the edid check at
> > runtime should be made possible, so that desktop environmens like KDE can
> > implement an manually override by specifying a firmware file or disable
> > the the edid check.
> 
> I think generally the solution would be a quirk, but we don't really
> have a mechanism to identify displays based on half-read EDIDs. Chicken
> and egg.

I would really like to see a solution here (without user interaction).

What about to have a hardware capability list for monitors containing the possible 
resolutions?

Another idea could be a way that the edid could be loaded dynamically later (as initrd 
time). Then it would be possible to genereate the necessary modelines and supply it.

> And then there's the problem that it's not just the checksum that
> appears to be wrong here. The workaround pretty much is the edid
> firmware option.

I know but I don’t prefer that.

 
> > References:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/712075[2]
> > https://lists.freedesktop.org/archives/dri-devel/2011-January/006778.html[
> > 1]
> > 
> > 
> > Monitor edid:
> > monitor-get-edid | hexdump
> > 0000000 ff00 ffff ffff 00ff e430 025a 0000 0000
> > 0000010 1300 0401 2595 7817 4402 9c75 5459 2796
> > 0000020 5023 0054 0000 0101 0101 0101 0101 0101
> > 0000030 0101 0101 0101 37c8 6480 b070 400f 2022
> > 0000040 0036 e672 0010 1a00 283c a080 b070 4023
> > 0000050 2030 0036 e672 0010 1a00 0000 fe00 4800

[-- Attachment #1.2: Type: text/html, Size: 21344 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: drm/edid: Add kernel parameter for override edid check

[Doug Anderson]

Hi,

On Mon, Nov 3, 2025 at 5:39 AM Jani Nikula <jani.nikula@intel.com> wrote:
>
> > The only workaround to get the higher resolution working is to provide a edid firmware
> > file using the parameter “edid_firmware”. This needs to be created manually and build into
> > the initrd to be available early at runtime.
> > I think the workaround isn’t very user friendly.
> > Putting a flag to disable the edid strict check would help more people get their moditors
> > more easy runnning by their own responsibilty.
> >
> >
> > At a later time I think a solution for controlling the edid check at runtime should be made
> > possible, so that desktop environmens like KDE can implement an manually override by
> > specifying a firmware file or disable the the edid check.
>
> I think generally the solution would be a quirk, but we don't really
> have a mechanism to identify displays based on half-read EDIDs. Chicken
> and egg.
>
> And then there's the problem that it's not just the checksum that
> appears to be wrong here. The workaround pretty much is the edid
> firmware option.

FWIW, I know when we were working on panel-edp.c someone mentioned
that if EDID identifiers weren't good enough then potentially we could
get IDs straight from DPCD. In theory I think there are ID registers
from 0x403-0x40b. I don't know how consistently monitors set those
correctly. ...but I guess that would only work for DP and maybe the
monitors that are failing are old HDMI / DVI ones?

Hmmm, though as long as the EDID was consistently corrupt in the same
way then it seems like maybe we could still solve it. If the EDID
looks corrupt then we could hash the EDID and then look the hash up in
a "corrupt EDID fixups table". If we find a match then we could
include instructions for how to deal with that corrupt EDID. Of
course, someone would need to write that code...


-Doug