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

[Christoph Thielecke <christoph.thielecke@gmx.de>]

[-- 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 --]