Custom Resolution Utility (CRU) Work in Progress

[ToastyX]

It has been a while since CRU has had a major update. I've been working on rewriting CRU from scratch, but it's taking longer than I'd like, so I thought I'd release a work in progress to give advanced users something to play with. Some features have not been reimplemented yet, and it has not been fully tested. This will not be the UI for CRU 2.0. CRU 2.0 will have an easier consolidated mode with a new layout and an advanced mode. This is more like the advanced mode but with the old layout.

Download: cru-test-2026-01.zip

Important differences:

• Descriptors such as "Name" and "Range limits" are now edited from the "Detailed resolutions and descriptors" list in the main window. Use the "Edit..." button under the list and not the button at the top of the window.
• Standard resolution descriptors are no longer added automatically. To add more than 8 standard resolutions, add a "Standard resolutions" descriptor manually, or add a "VTB-EXT" extension block.
• YCbCr 4:2:2/4:4:4 for HDMI is now in the CTA-861 extension block window. For DisplayPort, use the "Edit..." button at the top of the main window.
• "TV resolutions" data block has been renamed to "Video resolutions" to align with CTA terminology.
• Interlaced detailed resolutions vertical timing parameters are now per frame to avoid confusing resolution changes and for consistency with DisplayID. For EDID detailed resolutions, the vertical active resolution, front porch, and sync width must be even, and the back porch, blanking, and total must be odd.
  

Major changes:

• The display list now only contains active displays and inactive displays with overrides
• The "Edit..." button at the top now contains EDID properties such as product identification, display parameters, and color characteristics
• All detailed resolution fields can now be edited (use the triangle button to show all fields)
  • Sync type should always be "Digital separate" even with CRT monitors
  • Borders are only supported by NVIDIA
  • Added OVT standard
    
• All descriptors are now supported
  • Range limits now supports all timing definitions
  • CVT and Established III resolutions are not commonly used and only work with EDID 1.4 (normally used with DisplayPort only)
  • Color point and color management are not commonly used and have no effect in Windows
    
• Extension blocks are now readable with all GPUs including Intel
• Extension block header fields can now be edited
• FreeSync data block HDR profiles can now be edited
• HDMI data block 3D fields can now be edited
• HDR static metadata data block now shows actual luminance values along with the raw values
• New CTA-861 data blocks:
  • G-SYNC
  • HDR dynamic metadata
  • HDR10+
  • Microsoft head-mounted and specialized displays
  • Native video resolution
  • Product information
  • Vendor-specific
  • Video format preference
  • Video format resolutions
    
• New DisplayID data blocks
• VTB extension blocks now support CVT resolutions (not commonly used)
• Import will now always import the complete EDID
• Dark mode is now supported

[intimki]

CRU only works if IOMMU is enabled in the BIOS. Otherwise, Windows simply freezes during the driver initialization phase on the boot screen. How can I fix this? I don't want to have to enable IOMMU all the time
NVIDIA RTX 3080, Driver 596.02

[ToastyX]

(04-14-2026 02:16 AM)intimki Wrote:  CRU only works if IOMMU is enabled in the BIOS. Otherwise, Windows simply freezes during the driver initialization phase on the boot screen. How can I fix this? I don't want to have to enable IOMMU all the time
NVIDIA RTX 3080, Driver 596.02

Do you have multiple displays connected? NVIDIA's driver has a bug that can cause Windows to hang during boot when an EDID override is present with multiple displays connected and G-SYNC enabled. There is a workaround using scripts: https://www.monitortests.com/forum/Threa...wn-scripts

[intimki]

(04-14-2026 02:54 AM)ToastyX Wrote:  

(04-14-2026 02:16 AM)intimki Wrote:  CRU only works if IOMMU is enabled in the BIOS. Otherwise, Windows simply freezes during the driver initialization phase on the boot screen. How can I fix this? I don't want to have to enable IOMMU all the time
NVIDIA RTX 3080, Driver 596.02

Do you have multiple displays connected? NVIDIA's driver has a bug that can cause Windows to hang during boot when an EDID override is present with multiple displays connected and G-SYNC enabled. There is a workaround using scripts: https://www.monitortests.com/forum/Threa...wn-scripts

I actually have two monitors, but I tested various methods with just one connected. It makes absolutely no difference.
In addition, the script, as a general solution, is just a one-time fix. The reason is: reboots, accidental power outages, etc., when the EDID reset won’t have time to take effect. In any case, resetting the EDID won’t help on the next boot unless you apply it in advance every time before shutting down

[ToastyX]

(04-14-2026 04:27 AM)intimki Wrote:  I actually have two monitors, but I tested various methods with just one connected. It makes absolutely no difference.
In addition, the script, as a general solution, is just a one-time fix. The reason is: reboots, accidental power outages, etc., when the EDID reset won’t have time to take effect. In any case, resetting the EDID won’t help on the next boot unless you apply it in advance every time before shutting down

This can only be an NVIDIA driver bug. The IOMMU must be preventing the driver from hanging. This must be a new bug because I'm not aware of this happening with a single monitor connected. The workaround includes making a shutdown script, but you can actually reset the EDID immediately after restarting the driver instead. The EDID override will still be in effect as long as the driver doesn't restart.

[winterkid09]

Hi Toasty,

I believe that cru-test-2026-01 is mis-handling color-depth support for YCbCr 4:2:2 & YCbCr 4:2:0 encoding, it seems the Display Interface Features block within DisplayID 2.0 extension doesn't actually support 6bpc these two, so bit 0 should flag support for 8bpc instead of 6bpc

By the way, this version of CRU is super impressive! Seriously, nice work ~~

[ToastyX]

(07-19-2026 09:36 PM)winterkid09 Wrote:  Hi Toasty,

I believe that cru-test-2026-01 is mis-handling color-depth support for YCbCr 4:2:2 & YCbCr 4:2:0 encoding, it seems the Display Interface Features block within DisplayID 2.0 extension doesn't actually support 6bpc these two, so bit 0 should flag support for 8bpc instead of 6bpc

By the way, this version of CRU is super impressive! Seriously, nice work ~~

I just checked and you're right. I haven't been working on it lately, but I'll make sure that's fixed in the next release.

[archagon]

ToastyX, thank you for this excellent tool! I was wondering if you could help me understand something about EDID and DisplayID metadata. I'm trying to debug the behavior of Apple's Studio Display XDR using the latest Nvidia drivers. According to an Nvidia rep, their drivers used to use EDID identification for this display, but they recently enabled some sort of newer metadata path, which I assume means DisplayID 2.x. Using Nvidia's latest drivers with this display breaks some of its features: HDR and VRR support go away and it now shows up as a "Generic Non-PnP Monitor" instead of "Studio XDR." (However, the listed resolutions and refresh rates are still correct.)

I'd like to examine the full EDID/DisplayID metadata for this monitor, but I can't figure out how to do it. Using CRU with Nvidia's older (EDID) display drivers, I can see the expected EDID block, a CTA-861 block with HDR data, and a few DisplayID 1.x extension blocks, but no DisplayID 2.x blocks are to be seen. If I install the latest Nvidia drivers, CRU doesn't detect any EDID (or other) metadata for the "Generic Non-PnP Monitor" at all.

Are the OS and/or GPU drivers are intercepting this data before it ever gets to CRU? Do you know if there's a way to dump the full, untruncated EDID and DisplayID 2.x data from the display? Thank you!

[ToastyX]

(07-31-2026 03:13 AM)archagon Wrote:  ToastyX, thank you for this excellent tool! I was wondering if you could help me understand something about EDID and DisplayID metadata. I'm trying to debug the behavior of Apple's Studio Display XDR using the latest Nvidia drivers. According to an Nvidia rep, their drivers used to use EDID identification for this display, but they recently enabled some sort of newer metadata path, which I assume means DisplayID 2.x. Using Nvidia's latest drivers with this display breaks some of its features: HDR and VRR support go away and it now shows up as a "Generic Non-PnP Monitor" instead of "Studio XDR." (However, the listed resolutions and refresh rates are still correct.)

I'd like to examine the full EDID/DisplayID metadata for this monitor, but I can't figure out how to do it. Using CRU with Nvidia's older (EDID) display drivers, I can see the expected EDID block, a CTA-861 block with HDR data, and a few DisplayID 1.x extension blocks, but no DisplayID 2.x blocks are to be seen. If I install the latest Nvidia drivers, CRU doesn't detect any EDID (or other) metadata for the "Generic Non-PnP Monitor" at all.

Are the OS and/or GPU drivers are intercepting this data before it ever gets to CRU? Do you know if there's a way to dump the full, untruncated EDID and DisplayID 2.x data from the display? Thank you!

The XDR displays don't have DisplayID 2.x extension blocks. CRU with older NVIDIA drivers is showing the correct information. Also if it's using multi-stream transport, there may be two tiles, which should show as two separate displays in CRU.

Normally "Generic Non-PnP Monitor" means the graphics driver couldn't read a valid EDID, but if you're getting the correct resolutions and refresh rates, then the driver is using some other information, which could be pure DisplayID. I'm not sure how pure DisplayID is handled with Windows drivers because I don't have any hardware with pure DisplayID. "Generic Non-PnP Monitor" implies it doesn't use the same mechanism as EDID, so there might not be a standard way to retreive/override pure DisplayID.

[archagon]

Thank you. I know very little about how all this works under the hood, but from reading between the lines, it does sound like some separate path from the normal EDID/extension block mechanism. The rep said this:

Quote:Previous R590 driver branch relied on EDID to communicate with the monitor. However, the monitor also supports a newer display technology that was not fully supported in the R595 driver branch (which was the first branch that exposed it) but is supported beginning with the R610 branch.

And the SDXDR whitepaper mentions the following:

Quote:In Windows and Linux environments, the display uses VESA DisplayID and Extended Display Identification Data (EDID) to communicate capabilities and optimize resolution settings through USB-C Alt Mode or Thunderbolt 5 connectivity.

I'm guessing Apple is doing something unusual that few other monitors are doing, and there's some sort of mismatch between Apple/Nvidia expectations. Wish I could see the actual data Nvidia is working with here...