According to http://www.edidreader.com your existing EDID is valid. I wish I knew which exact piece of software is saying “EDID does not conform” (it may be more than one software location which does not like an extension), but from what I can see it shouldn’t be saying this.
One thing useful to know is that the first block is the original DDC and contains modes which were part of earlier monitors prior to wide screen (think 640x480 or 800x600). DDC blocks should always be valid and always be readable. Extensions are based on some newer monitor formats, e.g., I think the first EDID extension to DDC is when 1080p was added. Further extensions are added for newer modes like Ultra-High Def. If the modes are being parsed under a standard which predates one of the extensions then it would be normal to ignore the newer modes from a standard the video card does not support (perhaps without even complaining…unknown mode blocks should be ignored and not generate an error which stops parsing). The TX2 though should support even UHD, and the modes listed at edidreader.com should all succeed on a JTX2.
EDID is used to automatically fill in sections of the xorg.conf file via hotplug, in RAM, without writing any permanent file. It may be possible you can rewrite EDID in a way that gets this process working, but if that isn’t the case, you can choose to set Xorg to ignore EDID and manually fill in modelines within xorg.conf. You’d need details on your monitor timings. If you are interested in that, this is an example modeline generator you may find useful: https://arachnoid.com/modelines/
Yes, it is a “valid” EDID, but it does not expose the native mode of the panel.
This is quite likely because of cut-rate Chinese manufacturing practices.
You will note that it claims to be a 37" TV, but it’s actually a 7" IPS monitor.
This is all already mentioned earlier in the thread.
I appreciate your attempt to help. However, to save yourself some time, I suggest you read through this thread in a little more detail, because I tried exactly that, and the output is documented further up in this thread.
Trying to provide a modeline, and telling the driver to not require the format to be in the EDID fails, because the driver claims that the “AllowNonEDIDModes” option is unknown.
After a few false starts, I think I found an EDID editor that will actually work. The Phoenix EDID editor doesn’t work with extensions and the linux ones failed in various other ways when I tried to use them. One that appears to work is the “Analog Way” editor. Their editor is free and can be downloaded from www.analogway.com (Windows/MacOS) and via:
Support->downloads->AW EDID Editor
and then Software->AW EDID Editor for Windows [or MacOS]
To load the EDID, I had modified the original you posted into this format and saved this as “edid.dat”:
Then in the program, I could use Tool->Import to import this .dat file. If you go to Tool->Hexa Viewer, you can see it has the correct hex. Then I exported with Tool->Export and checked to make sure it made the same file as output without losing anything. It looks correct. So, it looks like this editor can read/write that EDID file. One nice feature the program is is the Hexa Viewer page (not the Tool->Hexa Viewer) where I can click on any of the hex and see what section it decodes to, for the basic blocks, anyway.
How would I go about doing that? i’m having a similar problem with a jetson nano not being able to read my display’s EDID properly and i’ll try anything i need to do to get it to work, because this specific display is the only one I can use for my project