- Moderator
- #31
Maybe it can instead of using the Windows provided display number (\\Display 1 etc..) use a unique display identifier, know that Ultramon does it this way with multi monitor setups which works pretty well.
Hardware id identifier seems the safest as that is unique for the connected display and should never change, not sure how the device is re-attached during refresh rate change but maybe it can be forced to a device based on their unique ID instead of the display # which can be temporarily different during the switch.
Just my 2 cents
Yep i have this idea too but not to strong in c# and c++ to do it (when i have try) maybe i could retry again
Yesterday, i have try to use deviceid but it was the same deviceid for 2 screen(s) so same GPU card (i have both GPU on dev for testing).
So need to find something else, with the recent change made ysterday, i use name + \\Display 1 etc. so it's better but maybe not full enough.
Yep i have adapted the change too on MP.exe along with config.exe
We will see what happen and see if we can force to not update setting.
From what i have seen, it seems that the primary display can change (swap) when device if off (1920x1080).
It's like Primary display can be 1600 or 1920. (Strange isn't it lol ?)
Interesting, is it possibile that change is related to dynamic refresh rate? so during the refresh rate on the main display MP check its state and found that it's not active for a while so it try to use the other one?
rembember the problem is sometimes when I start a play 24P on a 60 HZ, dynamic refresh rate start , the screen became blank for a while on the main display (It's correct), MP goes to other display for an instant (wrong) , and back to the main one but in a window not full screen with a messy playback
Maybe it's related but if i remember correctly, when MP start, it use the monitor set in MP config, D3D device is using it and create a pointer for C++.
So this D3D pointer never change and stay like this, MP windows can move his own window fullscreen or not but the D3D device stay the same.
Know the delay introduce, can be that MP try to do a DRR to the non available screen. But it should not because it's not the screen used on start.
I remember working on that part with @Owlsroost because before MP try to do refresh rate to a wrong monitor or non-existant one @vuego can explain too and before he must use eventghost to do a proper DRR.
So for me MP can handle correctly the screen to refresh but if MP is somehow on a wrong screen maybe DRR didn't work correctly (long time we did this change but i think the code to ask for DRR enumerate all current detected screen and do a comparaison to the current MP used screen and start the DRR.
So maybe the current MP used screen is fucked and then trigger the DRR delay.
It will be really good to know how to reproduce it to know what happen exactly