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
signature.asc
Description: This is a digitally signed message part.
