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
> > 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?
This I read out directly using get-edid, wrongly feed to hexdump.
The correct one is:
get-edid | parse-edid
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 2
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
No EDID on bus 7
No EDID on bus 8
No EDID on bus 9
2 potential busses found: 1 3
Will scan through until the first EDID is found.
Pass a bus number as an option to this program to go only for that one.
Bus 1 doesn't really have an EDID...
128-byte EDID successfully retrieved from i2c bus 3
Looks like i2c was successful. Have a good day.
Checksum Correct
Section "Monitor"
Identifier "��"
ModelName "��"
VendorName "LGD"
# Monitor Manufactured week 0 of 2009
# EDID version 1.4
# Digital Display
DisplaySize 370 230
Gamma 2.20
Option "DPMS" "false"
Modeline "Mode 0" +hsync -vsync
Modeline "Mode 1" +hsync -vsync
EndSection
Hope that helps.
Best regards
Christoph.
> 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