03-10-2023, 07:53 AM
(03-09-2023 10:50 PM)ToastyX Wrote: [ -> ](03-09-2023 04:37 PM)Parallellines Wrote: [ -> ]Including it still broke the resolutions. As I said, it happens with any edits whatsoever and I only used the Freesync range value as a quick example.It's not that simple. Every behavior in CRU is done for a reason. CRU was not originally meant to be a complete EDID editor, so certain values are always set a certain way; otherwise I would have to design a UI that allows users to edit fields that have no effect. I also have workarounds for certain driver bugs and invalid values so users don't have to worry about that stuff.
I also took the opportunity to do another test: I reset everything and simply imported the default, untouched EDID using CRU. That still broke the resolutions somehow.
And yes, the hex edit isn't special, but shouldn't CRU only touch the absolutely required bytes instead of messing with the rest of the file structure? These issues stem from those other edited bytes.
CRU 2.0 will be redesigned to be a more complete EDID editor, but there are still some cases where it may not be possible to preserve the original data, such as cases where the data has invalid parts that cannot be properly represented, which CRU 1.x currently fixes or removes automatically. I'm currently trying to think up a design that would allow CRU to handle and report all these situations without complicating the UI, and that significantly complicates the implementation.
I can explain every difference highlighted in your screenshot:
Bytes 0x23-0x25 (25 6b 80 / 25 4b 00): This is the list of established resolutions. CRU does not include certain resolutions that are ignored by Windows graphics drivers because I didn't want to clutter the list with resolutions that have no effect in Windows. In this case, the CRU version does not include 832x624 @ 75 Hz and 1152x870 @ 75 Hz because those resolutions are meant for old Macs. CRU 2.0 will include the complete list.
1e 4e 31 / 80 0e 21 (4 instances): This is the image size fields in each detailed resolution. This information is not used for anything in Windows, so CRU just sets a generic value (resolution ÷ 4). The reason it uses a generic value instead of preserving the original value is because if you add a new detailed resolution, there is no value to preserve, and I didn't want to add image size fields just to have people ask what they should put in there because it doesn't matter. I also wanted the result to be consistent if I deleted and recreated a resolution. For CRU 2.0, I want to allow editing the image size fields, but I'm still debating how to handle this because I also want to be able to copy and paste between different types of detailed resolutions, some of which might not have image size fields, such as DisplayID detailed resolutions.
Bytes 0x5a-0x7d: These are the last two detailed resolution or descriptor slots. The only reason this part is different is because CRU doesn't include the range limits by default except for DisplayPort monitors with FreeSync. This is done because it uses up a detailed resolution slot and can cause custom resolutions to be ignored if the driver uses this information. For instance, AMD listens to the max pixel clock for non-HDMI connections, but not NVIDIA. If you include the range limits, then this part should be the same in this case. CRU 2.0 will list descriptors separately and preserve them.
Byte 0x83 (f1 vs. 70): This is in the CTA-861 extension block. The first digit is four flags: YCbCr 4:2:2, YCbCr 4:4:4, basic audio, and underscan for PC resolutions. The only difference is CRU does not set the underscan flag unless it's also set in a video capability data block because Windows does not use this information. The second digit is the total number of native detailed resolutions. This is the only other difference I can think of that might be triggering the bug. I intentionally set it to 0, which means undefined, to make sure only the first detailed resolution is considered the native resolution. Technically 1 would mean the same thing, so if setting the second digit to 1 fixes the problem, then that's definitely an AMD driver bug, and I will have to force it to be 1 instead to work around the problem. This is a good example of why CRU needs to set certain values because otherwise the user would have to deal with this manually.
Bytes 0x7f and 0xff: These are checksums that are automatically calculated.
(03-09-2023 04:37 PM)Parallellines Wrote: [ -> ]On a related note, I forgot to mention that I had a weird issue with my 580. Whenever the monitor would wake from sleep the entire screen would be dim except for the mouse cursor and the fix was to change the resolution or press CTRL+SHIFT+WIN+B. Again, that only happened when I made edits with CRU and I just dealt with it for years and didn't think much about it. This doesn't happen anymore with the 5700XT.This is a different AMD driver bug that doesn't seem to be triggered by anything particular in the EDID. I think 19.11.2 was the last driver without the bug.
I appreciate the explanation. Changing the number of detailed resolutions from 0 to 1 fixed the issue, so it's an AMD driver bug indeed.
