System Configuration
- GPU: NVIDIA RTX 5090
- Monitors (Workstation Profile): Samsung 57" Odyssey Neo G9 + Samsung 49" Odyssey Neo G9 (both DisplayPort, DSC active)
- TV (Couch Gaming Profile): LG C1 OLED (HDMI)
- Software: DisplayFusion (Latest), Windows 11 Pro
The Problem
When switching between my "Workstation" profile (both Samsungs enabled, TV disabled) and "Couch Gaming" profile (TV enabled, Samsungs disabled), returning to the Workstation profile fails consistently.
Symptoms:
- Samsung monitors remain black or disabled after switching back from Couch Gaming profile
- Windows fails to recall correct display topology
- DisplayFusion cannot apply the profile because Monitor Hardware IDs have changed during the sleep/disconnect cycle
Root Cause (Confirmed):
The RTX 5090 combined with Samsung's DisplayPort DSC implementation causes monitors to generate
new Hardware IDs upon waking from deep sleep. This ID drift causes a mismatch with the IDs saved in DisplayFusion profiles.
Per ToastyX (CRU developer), NVIDIA's driver ignores EDID overrides when DSC is active and the resolution/refresh rate exceeds the GPU's single-head pixel clock limit (1620 MHz for RTX 5000-series). This prevents any software-based EDID locking from working.
Troubleshooting Completed
- Registry Reset: Deleted
HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
(Configuration, Connectivity, ScaleFactors) to wipe corrupted monitor history
- Driver Reset: Win + Ctrl + Shift + B successfully wakes GPU but doesn't resolve ID mismatch
- Profile Recreation: Deleted old profiles and created fresh "Workstation" and "Couch Gaming" profiles after registry reset
- DisplayFusion Settings:
- Enabled "Include Disabled Monitors in Saved Monitor Profiles for Matching"
- Disabled all Auto-Detect and Auto-Load Profile features (strictly manual switching via hotkey)
- Samsung OSD Settings: Power Saving Mode OFF, Auto Power Off OFF, Eco Timer OFF, Auto Source Switch+ OFF, PC/AV Mode set to PC
- Device Manager: No ghost monitors currently visible
Questions for the Community / Dev Team
Does DisplayFusion have any option to match monitors by
DisplayPort output path (physical connection) rather than Hardware ID? This would bypass the ID drift issue entirely.
Is there a way to configure profiles with
wildcard or partial ID matching for monitors that share the same model but generate different serial/ID strings?
Would a scripted function that calls
(CRU's driver restart utility) before applying a profile help force consistent ID detection?
Has anyone successfully used
hardware EDID emulators inline with DisplayPort cables to solve similar issues? If so, which products worked?
Any other suggestions for achieving reliable profile switching with high-refresh DSC monitors?
Additional Context
I'm aware of the
registry workaround to force NVIDIA to respect EDID overrides, but this caps pixel clock at 1620 MHz which would significantly reduce my refresh rate capabilities. Looking for solutions that preserve full 240Hz functionality if possible.
Appreciate any insights from those who've tackled similar multi-monitor DSC configurations. Happy to provide logs, screenshots, or additional diagnostic info.
Edit:
Update:
After further testing, I've discovered an additional issue that may be contributing to or separate from the ID drift problem.
When I attempt to switch back to the Workstation profile (dual Samsungs) using
DisplayFusion Remote, DisplayFusion appears to crash and freeze entirely. The application becomes unresponsive and the profile switch never completes.
This happens consistently when switching
to the dual Samsung configuration, but not when switching
away to the Couch Gaming profile (single LG TV).
I'm unsure if this is:
- A result of DisplayFusion trying to apply a profile to monitors with mismatched Hardware IDs
- An issue with enabling two high-resolution DSC displays simultaneously
- Something specific to profile switching via DisplayFusion Remote
- A combination of the above
Has anyone experienced crashes or freezes when switching to multi-monitor DSC configurations via Remote? Are there logs I should pull to help diagnose this?