Feedback for CRU 1.5.2 with 4090 and two DELL screens

[avenger]

I have rather a strange setup while I muster obsidians (money) to properly upgrade the whole thing. But here's what I have:

- Intel 4790K CPU
- 32GB DDR3 memory
- MSI Suprim Liquid X, RTX 4090
- Dell S2721dgf (1440p, 165Hz)
- Dell AW2724dm (1440p, 180Hz)
- LG "HD 16" (720p, 60Hz)

Both Dell screens are pugged to the 4090 DisplayPorts while the LG one is to my onboard intel graphics (via DB15 VGA).

My main purpose was to check if I could stop display port hotplug from screwing my desktop every time I turn on either (or both) dispay port screens. VGA one is kept fine when I turn off the LG screen. Only disconnects when I really push out the cable.

While installing the driver, I found the FreeSync range options and felt like trying them (bad idea!). Both screens are GSync *compatible* (thus, no dedicated module) but I read in the loaded settings, 48-165 (or 180) to both screens.

Pulled both screens to 1 min fps/hz and ran restart64. System froze, not even keyboard worked or hardware power button (to soft shutdown on press). VGA screen (on intel onboard) displayed the desktop and mouse, and it didn't move either. Completely frozen.

Reset button to the rescue. Turned on with only the tiny VGA one working. Opened CRU and changed the display IDs to something else. Changed "D" of "DELL" to "X" and went with that.

Reset64 and voila, freeze after several blinks of the screens. At least I had progress.

Reset button again. Booted up looking fine, all three screens working.

Went to nvidia pendulum (g-sync test program). Even though it was fully tied to the AW2724dm screen, the S2721dgf one went blanking out until it settled off. AW2724dm when going below 40Hz or so, blinked gray as if the textures were not being rendered at all. I guess it would be too good to be true to just unlock the range and work.

Back to CRU, reset the configs to just use the same EDID as it loaded from the screens with no change. Reset. Hang. Reset button.

Booted up fine, now nvidia pendulum is back to its normal >40fps gsync compatibility, and went to test the EDID persistence with the S2721dgf.

When it turned off, it screwed my desktop as usual, I guess CRU was never meant to act like that anyway.

But when powering the screen back on, guess what. Haze and lock ups again. So even if I kept the same settings CRU could read from my screens, it simply imposed something that made things super unstable I guess.

Then I ran reset-all as per instructions in the main CRU thread. Reset64 froze everything again. (what?) and then after the reboot I have everything reset, including primary screen pointing to the onboard one (it was initially on AW2724dm), but no longer freezes. Fortunately I could revert back (after repositioning the screens, etc) to where I was before CRU.

In the end it was fancy an experience, sad nothing worked out as I wanted and I am still looking forward to something that busts this most hated display port behavior when turning off screens.

The "solution" so far is running a script that switches to a power saving "power plan" (1 minute puts screens to standby) and runs the blank screen screensaver. But I can still see the computer "waking up" from time to time without exiting the screensaver. Some pesky background tasks are waking up the screens even though the screen saver stays on until I move the mouse around.

(then, back to the script, when the screen saver exits it prompts whether I want to switch back to the performance power plan so that it stops sleeping screens in 1 minute)

Hope this somehow helps other people trying to use CRU with similar peripherals... or hopes

[ToastyX]

CRU is not an EDID emulator, so it can't keep a display connected. It can only override EDIDs, so if the display disconnects, there is nothing to override.

If the system hangs when you make any change with CRU, that's a bug in NVIDIA's driver. There's a bug in the driver that can cause Windows to hang on boot with multiple displays connected, but that shouldn't happen with restart.exe unless you're hitting a different driver bug.

If the screen is waking up, it's because Windows detected some input somewhere. Some mice are overly sensitive and will detect movement intermittently even when you're not using it. The blank screen saver has a few pixels of leeway, but display sleep does not for some reason. Gamepads with analog sticks can also cause this.

[avenger]

(03-02-2025 03:23 AM)ToastyX Wrote:  CRU is not an EDID emulator, so it can't keep a display connected. It can only override EDIDs, so if the display disconnects, there is nothing to override.

Yup, I kind of had hopes it could have a setting to persist connection, ignore disconnection, etc. Would make sense if there was such a setting via software. Actually it seems drivers for nvidia quadro cards do have this option (create custom edids, not sure if persistent, from nvidia control panel). Probably there's a means to "unlock" this for other cards -- and that's what I thought could be a chance with CRU.
But I understand that's not the point of the tool -- at all.

(03-02-2025 03:23 AM)ToastyX Wrote:  If the system hangs when you make any change with CRU, that's a bug in NVIDIA's driver. There's a bug in the driver that can cause Windows to hang on boot with multiple displays connected, but that shouldn't happen with restart.exe unless you're hitting a different driver bug.

Ya, I could boot no problem. Once no video at all, then I had video but what I tried didn't work (reduce freesync range). The vga on onboard graphics really saved me from rebooting into safe mode etc etc.
The lock ups were exclusively on driver reset. Is that the same as win+ctrl+shift+b? Didn't really try the shortcut but that's also meant to reset/reload display driver. As the lock up was so hard, no F8 key could save the day.

(03-02-2025 03:23 AM)ToastyX Wrote:  If the screen is waking up, it's because Windows detected some input somewhere. Some mice are overly sensitive and will detect movement intermittently even when you're not using it. The blank screen saver has a few pixels of leeway, but display sleep does not for some reason. Gamepads with analog sticks can also cause this.

Pugging process monitor behind I could see several executables/dll triggered at the same time a screen wake happened. Like... low activity, and then a sudden bump of some apps/dlls, some right before it wakes, some right after, so I am guessing some scheduled task is poking the display without counting as actual input, as screen saver stays on. Virus/malware maybe -- very well hidden as I couldn't find anything suspicious in procmon sweep isolating a "de-standby" event.

It really makes sense some nvidia process to be among the list (as they are used to display stuff when waking up), but I also suspect of a bug or bad design in their software (both driver and nvidia app/overlay/etc) could be the culprit.

I could try to log mouse input somehow to see if it's registering "ghost movement" with all its almighty resolution. I don't really see the mouse occasionally skip pixels by itself even with the table shaking when I type so when I'm away that's even more surprising. Yet, what you said makes sense and perhaps something that wouldn't even ressult in a pixel move could be triggering the wakeup. Although I am still wary of the process bumps on wake events (all things considered).

Thanks for taking the time to share some insight to my issue, that's really annoying. I was so happy with my old QNIX passthru on DVI (and overclockable to 110Hz!) until I bought these DELL monsters that are chewing my sanity (although they really do better on displaying things than ol'QN!)

---

By the way, I was still on driver 566.36 from Dec 5th 2024 while I tested this. As 1.5.2 is (probably?) released Jan 2025, the super unstability even without changing anything could have been to the version.

Understanding CRU doesn't install DLL but just override registry settings, it is at the same time unlikely (cru version not tied to driver version) and likely (a registry setting valid on newer drivers or broken in older ones); so I might just have been unlucky in my mix-up of software and hardware to have it misbehave even with no changes.