Custom Resolution Utility (CRU)

[botounacruzeta]

(11-01-2020 11:28 PM)ToastyX Wrote:  CRU always includes the range limits first, name second, and serial number third so the most important one is first, and the less important ones can be "pushed off" the list when adding detailed resolutions. The original EDID has the serial number first, range limits second, and name third, but the order shouldn't matter, and the bytes are the same for each.

While testing, I thought about the order, but CRU doesn't allow to order "serial", "range limits", and "name".

Anyway, now with the problem fixed (after I have applied the "fix"), CRU shows range limits first, name second, and serial number, although I don't know if it shows the real order, or it will always show in the order it will include (if I save).

(11-01-2020 11:28 PM)ToastyX Wrote:  3. CRU does not set the number of native resolutions in the extension block, while the original EDID has it set to 1. This is the small change that I had you test, so this isn't the problem.

Is it the first byte in the hex string of

[Monitor.AddReg]
HKR,EDID_OVERRIDE,"0"

in the inf file?

If yes, I tried to change it in the inf file, and CRU displayed an error message when importing the file (probably because of the checksum, that wasn't changed)

(11-01-2020 11:28 PM)ToastyX Wrote:  Other than that, the checksums at the end of each block are different because of the changes, but they are correct. As far as I can tell, this is a driver bug because there is nothing wrong with the EDID override that CRU creates, and possibly any change to the first block would trigger the problem. CRU also makes these changes after importing a file, which is why the override is different from the original.

I really don't know why this issue is rare. It can be a combination of driver and specific hardware or settings.

Because I suppose if it was the driver alone, a lot of CRU users will be complaining about it.

Maybe it's related to this specific monitor...I don't know.