Custom Resolution Utility (CRU)

[ToastyX]

(03-09-2023 03:24 AM)Sabrehawk Wrote:  I was wondering if anyone here has an educated opinion about Samsung C4RG9x (32" super ultrawide, 5120x1440, 120hz)
using the available samsungmonitor driver and editing HDR STATIC METADATA to fix HDR Mode in Windows 11 dimming the desktop by ~25% compared to HDR off. (Yes the lumination slider is all the way to the right already,in HDR settings)

HDR is supposed to be dimmer than full brightness. The whole point of HDR is to use the brightest shades for the bright parts of HDR content only. If you want full brightness, disable HDR.

[Parallellines]

(03-09-2023 12:13 PM)ToastyX Wrote:  

(03-09-2023 03:46 AM)Parallellines Wrote:  I use HDMI, not DisplayPort, so setting the range there at the top wouldn't do anything. And yeah I suppose it's a driver bug indeed since everything worked normally with my 580.
I managed to figure out how to hex edit all my tweaks and this is the result with VSR enabled (now it properly adds the three resolutions at the top). I still had to apply it manually in the registry though, but that's okay I guess.

https://i.imgur.com/QphKzNh.png

Thanks for the replies anyway!

I need to know if including the range works or not, not just changing the range, which has no effect if it's not included. There's nothing special about your hex edit, so there's no reason why this shouldn't work with CRU.

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.

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.

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.

[Waldo]

I'm having a problem with my Philips 27M1F5800. The monitor is capable of outputting 3840x2160 @ 144Hz, 120Hz, etc... but I can only find 3840x2160 @ 60Hz, and then a load of lower resolutions at 100Hz and 120Hz etc. I cannot find 3840x2160 @ 144Hz or 120Hz anywhere.

Can someone help me find the resolutions I see in Windows?

The GPU is a 4090

https://i.ibb.co/6sY087x/Screenshot-1.jpg

https://i.ibb.co/n1rhZSz/Screenshot-3.jpg

[ToastyX]

(03-09-2023 05:21 PM)Waldo Wrote:  I'm having a problem with my Philips 27M1F5800. The monitor is capable of outputting 3840x2160 @ 144Hz, 120Hz, etc... but I can only find 3840x2160 @ 60Hz, and then a load of lower resolutions at 100Hz and 120Hz etc. I cannot find 3840x2160 @ 144Hz or 120Hz anywhere.

Can someone help me find the resolutions I see in Windows?

They're in the DisplayID extension block.

[ToastyX]

(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.

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.

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.

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.

[dkjfksd1892]

I've been trying to add 1440x1080 to my monitor for a while, tried a lot of the timing modes but monitor always complains about being out of range. Is there some other fine tune things I can try to achieve it? I've attached the edid incase it is of any help

[Parallellines]

(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.

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.

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.

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.

[thezagreus]

Hello, i have RX 6700XT, my monitor successfully overclocking to 85 Hz on 1280x960. But I can not overclock it to 80 Hz on 1920x1080.

Previously, I had nvidia (gtx 1060) and I did it successfully (overclock 80hz on FHD). Now, I can't do it. Is this a AMD driver issue?

My max results on FHD on rx6700xt - 71hz. (AMD Adrenalin does not allow you to create another profile. Error: display does not support)

P.S: I connected my GTX 1060 with a DVI-D TO DVI-D cable. Now, i connected my RX 6700XT a HDMI to DVI-D.
AMD DRIVER: 23.2.1

[MightyEagle82]

(03-09-2023 12:00 AM)ToastyX Wrote:  

(03-08-2023 09:40 PM)MightyEagle82 Wrote:  I want to use the app in WinPE which does not have 32-bit subsystem. Could you build 64-bit version of the app?
I really need it. I have bought a laptop with UHD display but it looks like Windows 10 PE does not support it. And by default it uses 800x600 or 1024x768 that is not enough for applications which I run. So CRU would help me a lot with this.

I can't make a 64-bit version until 2.x because the compiler and frameworks I used to create 1.x are too old. CRU would not have an effect in such an environment anyway. CRU needs a graphics driver that supports EDID overrides.

It sounds strange for me because I use only one WinPE image (built from Windows 10 ADK without any drivers) on 2 laptop: one with FHD display and another with UHD display. On the first one native resolution is set after the boot, but on the second one - low (possible 800x600). Maybe it depends on UEFI of specific laptop. But I'm not an expert in this field.

[0ka]

is there a way to save and load custom resolutions of the amd driver? without driver restart