Main > Software Forum
[Discontinued][17-09-22] RatRefresh - refresh rate switcher, stops LCD tearing
TitanGorilla:
I'm happy to help! I was able to get 0.11 working but it did take some time configuring CRU to get it working properly. I used CRU to remove every default setting except for one or two custom refresh rate values to ensure it was using the right EDID value. For some reason though, after using CRU with 0.11 it's showing a higher than expected range of min and max refresh rates when I attempted to get it working for 0.14 and 0.15.
I also think I fixed the screen tearing issue I was having. I used the Display Driver Uninstall utility and also changed some settings in Nvidia Control panel after re-installing the drivers. I think re-installing the drivers with DDU first most likely fixed my screen tearing issue.
I tried extensively to get 0.14 and the 0.15 debug version working but had no luck. It seems like the EDID override in 0.14/0.15 might not be writing to the correct registry value. I noticed when either using 0.14 or the 0.15 debug version, there are multiple refresh rates showing in the Windows Advanced display settings. The newer versions also seem to override the custom refresh values I set with CRU by giving a range of refresh rate values in Advanced display settings. I noticed even with 0.11, I couldn't get the refresh rate to change if there were the default refresh rate values showing. With CRU I had to remove all of the default values and only set 1 or 2 custom resolution/refresh rates, then restart my machine to set it to the refresh rate being overridden in the registry, and use the 0.11 version to get it working.
Rataplan727:
--- Quote from: TitanGorilla on March 08, 2023, 11:33:26 pm ---I'm happy to help! I was able to get 0.11 working but it did take some time configuring CRU to get it working properly. I used CRU to remove every default setting except for one or two custom refresh rate values to ensure it was using the right EDID value. For some reason though, after using CRU with 0.11 it's showing a higher than expected range of min and max refresh rates when I attempted to get it working for 0.14 and 0.15.
I also think I fixed the screen tearing issue I was having. I used the Display Driver Uninstall utility and also changed some settings in Nvidia Control panel after re-installing the drivers. I think re-installing the drivers with DDU first most likely fixed my screen tearing issue.
I tried extensively to get 0.14 and the 0.15 debug version working but had no luck. It seems like the EDID override in 0.14/0.15 might not be writing to the correct registry value. I noticed when either using 0.14 or the 0.15 debug version, there are multiple refresh rates showing in the Windows Advanced display settings. The newer versions also seem to override the custom refresh values I set with CRU by giving a range of refresh rate values in Advanced display settings. I noticed even with 0.11, I couldn't get the refresh rate to change if there were the default refresh rate values showing. With CRU I had to remove all of the default values and only set 1 or 2 custom resolution/refresh rates, then restart my machine to set it to the refresh rate being overridden in the registry, and use the 0.11 version to get it working.
--- End quote ---
Well, as stated before, 0.11 used the custom edid value, usually generated by CRU, and changed the pixelclocks & checksum in THAT custom value. 0.14 and 0.15 take the monitors own EDID (ie the EDID vavlue, and not the EDID_OVERRIDE\0 value) and change that. The reason for that thinking was when the custom key got corrupted or something, using the original one helps. I initially was under the impression that CRU just did the same; use the original EDID and change pixelclock / resolution accordingly. It seems though it changes some more things. However, when you change the refreshrate using CRU when you already have a custom rate from CRU, the exact two bytes that it changes are the same as RatRefresh does.
Now for something I never had to think of before; my CAB has a Dell Ultrasharp 2415+ which uses EDID 1.3 if I remember correctly. But the EDID values you guys with issues post all are EDID 1.4. There might be another issue.
For some reason things are very unconsistent for me. On my work NUC with 2x Dell U2421E, which are EDID 1.4 or higher, strange things happen. While I absolutely ONLY write to the EDID_OVERRIDE\0 value, as soon as the driver restarts, sometimes the monitors own EDID value also changes. When that happens things don't work. I think removing the monitors from device manager and have them redetected fixes that, but I've not had the time to work that out completely. The same happens when using CRU by the way for me, I've pasted an image before already where procmon clearly shows CRU writing to the monitors EDID value as well as to the override value.
What you could test to help me is set things up to work with RatRefresh 0.11. Then use 0.15 as following:
--- Code: ---RatRefresh -min 50 -max 65 -usecustomedid -refresh 59.150
--- End code ---
The crux there is the -usecustomedid switch which makes it behave like before; it takes the existing custom EDID key (if it exists from CRU for example) and modifies that. he -min and -max should be supplied just in case RatRefresh isn't able to decode it itself.
btw sorry again for all the hassle and thank you so much for all the help in this :-)
trevorp:
In my case, the behavior is the same. 0.11 works, 0.15_debug does not
0.11
--- Code: ---D:\Utilities\RatRefresh>type edid.txt
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&5&UID4353\Device Parameters\EDID_OVERRIDE\0
--- End code ---
0.15_debug
--- Code: ---D:\Utilities\RatRefresh_0.15_debug>type edid.txt
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&5&UID4353
--- End code ---
--- Code: ---D:\Utilities\RatRefresh_0.15_debug>RatRefresh -min 50 -max 65 -usecustomedid -refresh 58.150
RatRefresh 0.15 debug build
Key SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&5&UID4353\Device Parameters\EDID_OVERRIDE
WantedRefreshRate 58.150
CalculatedPixelClock 26034
TotalChecksum 7736
Checksum 200
HexChecksum c8
done
--- End code ---
0.11 sets my rate to whatever I want, 0.15_debug keeps coming back to my 59.172 Hz rate
What's bizarre is I now have a third display in CRU, and one of them has the 59.171 Hz rate, though that's one I specifically don't call as my system seems to keep recreating it and defaulting to it.
I called 55.123, and my CRU was for
In the first and third CRU entries, it doesn't see the min/max rates, no serial number, etc. In the second one, which is the one it keeps switching to regardless of what I call, the min/max and serial are present.
[edit]
After running some more tests and watching what's going on with process monitor, I can confirm what you already have.
The exact same registry writes are happening with the same values.
I do see a timing difference between the two devconx64 calls in 0.11 and 0.15
0.11
--- Code: ---Time of Day Process Name PID Operation Path
56:06.5 RatRefresh.exe 9172 Process Create D:\Utilities\RatRefresh\devconx64.exe
56:09.0 RatRefresh.exe 9172 Process Create D:\Utilities\RatRefresh\devconx64.exe
--- End code ---
0.15_debug
--- Code: ---Time of Day Process Name PID Operation Path
59:38.7 RatRefresh.exe 2080 Process Create D:\Utilities\RatRefresh_0.15_debug\devconx64.exe
59:40.7 RatRefresh.exe 2080 Process Create D:\Utilities\RatRefresh_0.15_debug\devconx64.exe
--- End code ---
I mean it's 2.5s vs 2s, but is it possible it's just a timing issue?
I've got about 7000 lines of process monitor dump to parse through for each run of ratrefresh, was just skimming.
Rataplan626:
Oh crap could that be :o I lowered the delay to 1500ms... I'll test.
But yes that's the exact behaviour I see too. But not 100% reproducible yet. Btw got my account back :)
TitanGorilla:
I didn't have much luck either. It seems like the default extension blocks are being reset after running the command in .15. In CRU I removed every refresh rate value except the one custom value, including the default extension blocks. After running .15 it seems to override the custom value and only shows the default refresh rates in Windows Advanced display properties. If I delete the extension blocks in CRU, it works in .11 again.
Registry value before running .15.
Registry value and final outcome after running the command in .15. I didn't notice a difference in the Display Properties in CRU. The default extension blocks are now showing in CRU and the default refresh rates are showing in Advanced display properties instead of just the one custom refresh rate I set. If I remove the default extension blocks, the custom refresh rate shows again after restarting, and I'm able to use .11 again to set a new custom refresh rate.
Also, congrats on getting your account back! :)
Edit:
I noticed the custom refresh rate value does change in CRU after running the command in .15. It's possible the default extension block values are overriding the custom refresh rate value set. The new value is showing in CRU but it's not selectable in the Advanced display properties.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version