Custom Resolution Utility (CRU)

[ToastyX]

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

[Sabrehawk]

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)

Monitor driver used:
  C49RG9xSS.zip (Size: 7.89 MB / Downloads: 275)

OFC i did use search to find something applicable..but no luck.





The max brightness of this Screen is 1000 nits and its running in 10bit RGB via Display Port
GPU 3070 TI ,EVGA FTW3

i am a bit worried to mess around with it might cause major headache so id like to hear expert opinion about it first.

PS: im a bit puzzled that i dont see my native resolution anywhere in that screenshot btw ,strikes me as odd, the driver works fine otherwise

[Parallellines]

(03-08-2023 06:36 PM)ToastyX Wrote:  

(03-08-2023 05:08 PM)Parallellines Wrote:  These are my usual edits:
https://i.imgur.com/N6TIWO9.png

This is what the resolutions look like on Windows before and after any CRU edits:
https://i.imgur.com/DIgYPSl.png

The "Test" EDIDs are what I mentioned in my other post. For them, I only changed the value for the lower freesync limit and nothing else, just in three different ways:

1. Changed the 40hz lower bound to 30hz directly in CRU and exported the EDID
2. Hex edited the value in the default EDID and imported the file with CRU
3. Applied the hex edited EDID directly in the registry without using CRU

I thought CRU would only change the one byte responsible for the lower freesync limit and the checksum, but it made a bunch of other changes as you can see here (left side is the hex edited EDID and right is the CRU export). One or more of these changes break the resolutions available in Windows.

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

I expected tests #2 and #3 to yield identical results, but actually #2 was the same as #1. I rebooted and exported the previously imported hex edited EDID using CRU and the output file was the same as the direct CRU edit, byte for byte (I imagined that CRU would just accept the file and apply it directly, but instead it made edits).

The only way I could apply my hex edited EDID correctly was by adding it in the registry manually without CRU.

I tried hex editing my other usual tweaks but I couldn't figure out the rest of the file structure so I hoped you could help me with that. All I need is to extend the Freesync range and remove any resolutions above 2560x1080 (or at least just 3840x2160 I suppose, since 3840x1620 has the same aspect ratio as my native one) from the Windows selection menu while keeping the same recommended one.

CRU always sets certain things the same way for simplicity. The only major difference I see is CRU doesn't include the range limits by default except for FreeSync with DisplayPort. Does including the range limits using the "Edit..." button at the top fix the problem? This shouldn't be required except to define the FreeSync range with DisplayPort. I would consider this a driver bug because that shouldn't affect the recommended resolution, and if it were actually using that information, the 4K resolutions wouldn't be available. For HDMI, it's supposed to use the information in the HDMI data blocks, and for HDMI FreeSync, it's supposed to use the FreeSync data block.

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.



Thanks for the replies anyway!

[ToastyX]

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

[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