Hi, On Mon, Nov 3, 2025 at 5:39 AM Jani Nikula <[email protected]> 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
