Hi, we are using EEditGold for a long time now and are very happy to have it.
Now we are moving on to HDMI 2.1 and wanted to test some of the new features. However I found, that the VRR flags and fields (Cinema VRR, CNM VRR, Min. VRR, Max. VRR) appear in the dialog (VSDB) but are not saved in the EDID.
Is VRR not yet supported in 1.01.0268?
Hello,
Are these the fields you are talking about? The hex data in the top window are the exact data stored in the x.dat file. I was able to add, store and recall the edid file and I think the bits are working correctly. Are you talking about other fields or where am I confused?

Thanks for the prompt response.
Yes, these are the fields. For me the hex data don't change when I click the VRR flags and fields (Cinema VRR, CNM VRR, Min. VRR, Max. VRR). They do change for the other values. Here is a video: corsair-my.sharepoint.com/.../Eb4IGSkwv0VIkUhN1tTxOzgBGU6YN0eTkuQcXtkLrDXM0g
(I usually load EDIDs by importing .bin files. But I don't think that should make a difference.)
First thing I notice is your len=7 while my len=13. And the bits that are having problems are in bytes pass the 7th byte.
Can you send me the bin file so I can check it out here. Also can you save it as a .dat file and send it to me.
Initial suspicion is the bin file spec's the length at 7 and it stick there ignoring bits in bytes 7-12. Note in my picture above there's 14 bytes defining HF.
On a side note if it is overflow, you can add more CEA blocks to the EDID. I've seen 4 EDID blocks in some EDIDs and technically you can go up to 127 blocks.
I just checked the HDMI spec and the HF block is variable length of 7-31. I believe I hard fixed the code to always have 13 byte length. If this is true then this is a bug in the code. A temperary fix for this would be changing the HF block to len=13 bytes.
I'll see after I get your bin file.
I uploaded two HDMI 2.0 EDIDs to my sharepoint folder (see email). They have a length of 7 for the HF-VSDB and the VRR data cannot be stored.
For comparison I also uploaded two HDMI 2.1 EDIDs specifying a length of 8 respectively 10. In these EDIDs some of the HDMI 2.1 fields are stored but not all.
With 10 bytes I am able to store Min and MaxVRR.
It does appear that I've hard coded the HF block to 13 bytes. Unfortunately this requires code changes which will not occur over night. I'll pull they code and see if I can fix it soon.
For now the best work around I can offer is to create new EDID blocks with a 13 byte HF. and delete the original one.
Thanks for finding this bug. Please let me know about any other bugs. I'll let you know when I release a new version.
Mea Culpa
Fixed with new version 1.01.0276.
Thanks for the quick help
Fixed with new version 1.01.0276.
Thanks for the quick help