[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]

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.

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: [Select]

RatRefresh -min 50 -max 65 -usecustomedid -refresh 59.150 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: [Select]

D:\Utilities\RatRefresh>type edid.txt
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&5&UID4353\Device Parameters\EDID_OVERRIDE\0

0.15_debug

Code: [Select]

D:\Utilities\RatRefresh_0.15_debug>type edid.txt
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&5&UID4353


Code: [Select]

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

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: [Select]

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

0.15_debug

Code: [Select]

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

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  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.

[Rataplan626]

I've uploaded 0.15b4, it defaults back to 2 seconds delay before restarting the display driver, and it introduces a parameter -delay <ms> to change the delay. I would actually be surprised if the delay makes things not work. But it might, the delay was not in there for nothing. When I first just stopped and restarted without any delay, it didn't work either on my cab. Maybe 1500ms is just on the edge of working / not working on my system as it's so unpredictable. Then again, on my actual cab 0.15 works just fine, all versions are tested on my cab before shipping them out ;-)

On my home Intel NUC, old 5th gen one, it even works fine with delay 0. But I noticed on that machine when restarting videodrivers, I don't get the Windows hardware disconnected / connected sound, which I DO get on all other machines I tried on. So there's definitely some differences in how systems or different drivers behave. Also, when I remove all values, or even remove my display drivers and monitors completely and let them re-install, my refresh rate seems to be 59.850, were one might expect 60. So either that ufotest site is off by a bit, or my Intel iGPU doesn't actually do 60Hz when it's supposed to.

Anyway, as you saw with procmon (it's so helpful to have people 'on board' that can help debug to both of you) when you use -norestart and -usecustomedid, you can see the exact same values are written by 0.15 as 0.11. So please report on 0.15b4 I'd say, start with RatRefresh -remove, and then use RatRefresh -refresh <something> to start with. If that still doesn't work, use -remove again, and then setup CRU as you did with 0.11, and use RatRefresh -usecustomedid -refresh <something>, eventually with -delay 5000 or so to be sure.

[trevorp]

Grabbing coffee, so time for a quick update.

Getting 0.11 to work, then jumping to 0.15b4 still doesn't work with any delay.  Darn, I was hoping it was that easy.

Also of note, once I use 0.15b4, 0.11 ceases to work.  (when I say ceases to work, it comes back to the same 59.172 Hz as always) I have to delete the monitor and display adapter from control panel, reboot (not sure if necessary) and run CRU again.

I did try 0.11 -> 0.15b4 without customedid, then with customedid first, and that didn't work and borked 0.11.

I then did 0.11 -> 0.15b4 with customedid which didn't work, and also borked 0.11.

Will do more in-depth testing at lunch, just wanted to drop a note to let you know where I'm at.

Glad you got your account back as well.

[Rataplan626]

*sigh* it's getting out of hand :-)
Observations: I tried on three different systems to use CRU, and then use RatRefresh 0.11, set everything up fresh again, use CRU, run RatRefresh 0.15 -usecustomedid and the resulting custom edid was 100% identical in all ocasions, and on those machines worked fine as such.

More observations: when you delete monitors from Windows, and have the redetected, the monitors own EDID value that's written at for example 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\SDC424A\4&25831cb2&0&UID265988\Device Parameters', contains the EDID of the last used custom resolution, ie the EDID of the last refresh rate. If your last rate was 58.850, delete monitors and redetect them, the resulting EDID will be for 58.850Hz.
The same happens when you delete the monitors EDID and restart the video driver --> resulting EDID contains the last used refreshrate. Probably this happens as the monitors EDID is actually overwritten, hence it reports that EDID when you request it. So far for me to get back to the monitors actual EDID is removing monitors, removing the display adapter and then redetect things.
This results in strange behaviour. So parameter -remove now no longer removes the monitors own EDID anymore, only custom EDID.

Still I've not been able to even think of why 0.15 would not work to change a CRU generated value when -usecustomedid is used. To help myself I improved the -query parameter, which now shows more information on the monitors own edid and the custom edid. Link to 0.15b5 below.

So what you could verify is run RatRefresh -query, and see if the monitors own EDID makes any sense. Usually the refreshrate should be 60 or 75 or whatever you have. If the original value is not correct, remove monitors (remember to remove hidden monitors too) and display adapter, and then let windows scan for new hardware. All should be recreated correctly now. And on my systems here at home, they al work fine then without having to create a resolution with CRU.

0.15b5

[trevorp]

Code: [Select]

D:\Utilities\RatRefresh_0.15b5>RatRefresh.exe -query
RatRefresh 0.15 debug build 5

Monitors original EDID values:
Decoded EDID values:

HexCurrentPixelClock:      5fad
CurrentPixelClock:         24493
HexHorizontalResolution:   0a00
HorizontalResolution:      2560
HexVerticalResolution:     0640
VerticalResolution:        1600
HexVerticalBlankingLines:  002e
VerticalBlankingLines:     46
TotalHorizontalResolution: 2720
TotalVerticalResolution:   1646
Refreshrate:               54.707
Minimum refreshrate:       82
Maximum refreshrate:       70

Checksum stored in EDID: e2
Calculated Checksum:     e2
Featureblock 4 minimum and maximum refreshrate
Minimum: 82
Maximum: 70
Featureblock 3 minimum and maximum refreshrate
Minimum: 68
Maximum: 69
Featureblock 2 minimum and maximum refreshrate
Minimum: 49
Maximum: 86
Featureblock 1 minimum and maximum refreshrate
Minimum: 64
Maximum: 46
Monitors custom EDID values:
Decoded EDID values:

HexCurrentPixelClock:      5fad
CurrentPixelClock:         24493
HexHorizontalResolution:   0a00
HorizontalResolution:      2560
HexVerticalResolution:     0640
VerticalResolution:        1600
HexVerticalBlankingLines:  002e
VerticalBlankingLines:     46
TotalHorizontalResolution: 2720
TotalVerticalResolution:   1646
Refreshrate:               54.707
Minimum refreshrate:       82
Maximum refreshrate:       70

Checksum stored in EDID: e2
Calculated Checksum:     e2
Featureblock 4 minimum and maximum refreshrate
Minimum: 82
Maximum: 70
Featureblock 3 minimum and maximum refreshrate
Minimum: 68
Maximum: 69
Featureblock 2 minimum and maximum refreshrate
Minimum: 49
Maximum: 86
Featureblock 1 minimum and maximum refreshrate
Minimum: 64
Maximum: 46

54.707 is normal, last time I ran 0.11 that's the rate I picked.

I removed all monitors, including hidden ones, and all display adapters.

Afterwards, I see two U3014 detected, one hidden, one not.



After doing ratrefresh -setup and calling for a rate of 58.123, my rate still goes back to the 59.972 I always see.

Code: [Select]

D:\Utilities\RatRefresh_0.15b5>ratrefresh -setup
RatRefresh 0.15 debug build 5

Detected video drivers:
Name:                         NVIDIA GeForce GTX 780
Device ID:                    PCI\VEN_10DE&DEV_1004&SUBSYS_84691043&REV_A1\4&80E7924&0&0008

Detected active monitors:
Monitor number:               1
Monitor description:          DELL U3014
Serial number:                RF57P44EA4NL
Monitor InstanceID:           DISPLAY\DEL4083\5&67fc0b1&9&UID4353
Monitor DevicePath:
Monitor active:               True
HorizontalResolution:         2560
VerticalResolution:           1600
Minimum reported refreshrate: 49
Maximum reported refreshrate: 86


What monitor number to use?
1
edid.txt file written.


Code: [Select]

D:\Utilities\RatRefresh_0.15b5>ratrefresh -debug -refresh 58.123 -delay 2500
RatRefresh 0.15 debug build 5

-min Not supplied. Using EDID supplied value Of 49
-max Not supplied. Using EDID supplied value Of 86
Press key to continue.

Key SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&9&UID4353\Device Parameters\EDID_OVERRIDE
WantedRefreshRate 58.123
HexCurrentPixelClock: 6227
CurrentPixelClock: 25127
HexHorizontalResolution: 0a00
HorizontalResolution: 2560
HexVerticalResolution: 0640
VerticalResolution: 1600
HexVerticalBlankingLines: 002e
VerticalBlankingLines: 46
TotalHorizontalResolution: 2720
TotalVerticalResolution: 1646
CalculatedPixelClock 26022
HexCalculatedPixelClock 65a6
ReversedEdidHexCalculatedPixelClock a665
TotalChecksum 9631
Checksum 97
HexChecksum 61

Restarting videodriver with a delay of 2500ms

done
Press key to continue.

CRU shows the two entries with the custom modes listed above.





It still seems like it's updating one custom edid and using a different.

When I look back in the registry, the two entries in CRU correspond to the one you detect:

Code: [Select]

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&9&UID4353

and

Code: [Select]

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0

I'm going to format my NUC and toss win10 on it later today.  I want to see if it's my monitor causing this.  It won't eliminate the nvidia GPU, but at least will eliminate the monitor.

I've got an AMD I can toss in there too but that requires a bunch of disassembly, will start with the easy stuff first.

[Rataplan626]

I wouldn't reinstall, don't think that'll help. What DOES help is that I now see ratrefresh writes to the non-active monitor. Maybe thats the issue here. I'll try to find out what or why or when the non-active monitor exists. I think I can test that myself over here.

Still I don't see why .15 doesnt work after fully resetting everything and using -usecustomedid after usig cru to create a custom resolution.

Btw as far asI know the 1&8713bca&0&UID0 ID is  the generic monitor on the default graphics adapter you'll get when you remove the real devices from device manager.

[Edit]
I wonder, does CRU write in different registry keys when creating a resolution for either of the two Dells it shows?
Could you maybe export registry after creating for active, and then export after creating resolution for inactive?

[trevorp]

Will do the registry exports tomorrow.  Every time I promise to do it in a few hours, something comes up.  I'm going with "under promise, over deliver" at this point.

I wasn't planning on blowing away my cab, I just have an 11th gen NUC that is currently not being used.  Right now it's got Linux on it, but I don't mind blowing that away and dropping win10 on it temporarily, as I'm just curious.

[edit]

Still owe you more testing on the problem system, but I wanted to report that on the NUC 11 on a different Dell U3014 monitor, everything works as expected with 0.15b5.  I also don't see 1&8713bca&0&UID0 showing up under DELL4083.  I do still see two entries in CRU, and one of them is the 59.972 (59.971 in CRU) that's been stalking me.  This must just be the default rate of the monitor.

I used a different monitor as it was next to the NUC, but since they're the exact same model, I wanted to run a test.  Will move the NUC to test with the other monitor, but I expect no difference.

[edit2]
So as not to reply to myself, here are the results as promised

First off some images of the differences between the PC with the issues and nvidia GPU and the NUC.

Here's the original PC after running ratrefresh



Here's the NUC after running ratrefresh



Notice how the 1&8713bca&0&UID0 monitor is under the DELL4083 key on the problem PC, but it's under Default Monitor on the one that works.

I also see that on the NUC, it does create a new entry ending in UID0 but the first part of the key matches the Dell monitor, whereas on the problem PC it does not.

Rather than the registry exports, I used process monitor to monitor cru.exe and see what it did.

Here's CRU for the active monitor:

Code: [Select]

Operation Path Result Detail
RegCreateKey HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE REPARSE Desired Access: Set Value
RegCreateKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE SUCCESS Desired Access: Set Value, Disposition: REG_OPENED_EXISTING_KEY
RegSetInfoKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE SUCCESS KeySetInformationClass: KeySetHandleTagsInformation, Length: 0
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\0 SUCCESS Type: REG_BINARY, Length: 128, Data: 00 FF FF FF FF FF FF 00 10 AC 83 40 4C 4E 34 41
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\(Default) NAME NOT FOUND
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\CRU_Name SUCCESS Type: REG_BINARY, Length: 11, Data: 01 44 45 4C 4C 20 55 33 30 31 34
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\CRU_Serial_Number SUCCESS Type: REG_BINARY, Length: 13, Data: 01 52 46 35 37 50 34 34 45 41 34 4E 4C
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\CRU_Range_Limits SUCCESS Type: REG_BINARY, Length: 11, Data: 01 00 31 00 56 00 1D 00 71 01 18
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\CRU_Extensions SUCCESS Type: REG_BINARY, Length: 1, Data: 01
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\1 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\2 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\3 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\4 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\5 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\6 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE\7 NAME NOT FOUND
RegCloseKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID_OVERRIDE SUCCESS
RegOpenKey HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters REPARSE Desired Access: Set Value
RegOpenKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters SUCCESS Desired Access: Set Value
RegSetInfoKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters SUCCESS KeySetInformationClass: KeySetHandleTagsInformation, Length: 0
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID SUCCESS Type: REG_BINARY, Length: 256, Data: 00 FF FF FF FF FF FF 00 10 AC 83 40 4C 4E 34 41
RegCloseKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters SUCCESS

Here's CRU for the inactive monitor:

Code: [Select]

Operation Path Result Detail
RegCreateKey HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE REPARSE Desired Access: Set Value
RegCreateKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE SUCCESS Desired Access: Set Value, Disposition: REG_CREATED_NEW_KEY
RegSetInfoKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE SUCCESS KeySetInformationClass: KeySetHandleTagsInformation, Length: 0
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\0 SUCCESS Type: REG_BINARY, Length: 128, Data: 00 FF FF FF FF FF FF 00 10 AC 83 40 4C 4E 34 41
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\(Default) NAME NOT FOUND
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\CRU_Name SUCCESS Type: REG_BINARY, Length: 11, Data: 01 44 45 4C 4C 20 55 33 30 31 34
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\CRU_Serial_Number SUCCESS Type: REG_BINARY, Length: 13, Data: 00 52 46 35 37 50 34 34 45 41 34 4E 4C
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\CRU_Range_Limits SUCCESS Type: REG_BINARY, Length: 11, Data: 00 00 31 00 56 00 1D 00 71 01 18
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\CRU_Extensions SUCCESS Type: REG_BINARY, Length: 1, Data: 01
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\1 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\2 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\3 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\4 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\5 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\6 NAME NOT FOUND
RegDeleteValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE\7 NAME NOT FOUND
RegCloseKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\1&8713bca&0&UID0\Device Parameters\EDID_OVERRIDE SUCCESS
RegOpenKey HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters REPARSE Desired Access: Set Value
RegOpenKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters SUCCESS Desired Access: Set Value
RegSetInfoKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters SUCCESS KeySetInformationClass: KeySetHandleTagsInformation, Length: 0
RegSetValue HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters\EDID SUCCESS Type: REG_BINARY, Length: 256, Data: 00 FF FF FF FF FF FF 00 10 AC 83 40 4C 4E 34 41
RegCloseKey HKLM\System\CurrentControlSet\Enum\DISPLAY\DEL4083\5&67fc0b1&a&UID4353\Device Parameters SUCCESS

Interesting that on the inactive display it still writes to the active display as well.

Also of note, that 59.972 Hz rate that I keep ending up at is what's in the inactive monitor before I set a custom rate.

After I've set the custom rate and run ratrefresh, the custom rate I set for inactive stays, the rate for active updates to what ratrefresh calls for, but I still end up at 59.972 Hz rate, which now no longer shows in CRU at all.

I do have the registry exports, but they show the same, and this is pretty easy to digest.

[TitanGorilla]

It seems like .015b5 is giving me the same issue as before. The min and max refresh rate also might be a bit off from what was set with the -usecustomedid parameter.



Each time -refresh is run, the default extension block is reset.


After deleting the default extension block and restarting my machine, the refresh rate value I set is now being used and shows in Advanced display properties.


.11 doesn’t reset the extension blocks after -refresh is used. After running -refresh with a new value, after the drivers reset, it immediately changes to the new value in Advanced display settings.


-refresh alone doesn’t refresh the value in CRU, there are no resolutions and refresh rates present.


-usecustomedid with -refresh does set the new refresh rate value each time it's used.

Is there any possible way to have the -refresh command delete the default blocks, or can you create a separate parameter that allows you to delete these default blocks? Is it necessary to have default extension blocks? Maybe another parameter could be created to reset the default extension blocks if these are needed for some reason. .11 didn’t reset this in CRU and it seemed to work if you deleted the default extension blocks manually. If it's possible to have a command to delete these extension blocks and prevent them from being reset after -refresh is run, it might allow the new refresh rate to show and be used. It seems when the default blocks are reset to the default, the new refresh rate isn’t showing as available. If later versions deleted the extension blocks(or gave the option to delete these with a separate command) and prevented the Extension blocks from being reset when -refresh is used, it might allow the refresh rate to be used without having to restart the machine. The only other issue I noticed that might be preventing versions after .11 from working is the -refresh command doesn’t set the refresh rate value in CRU, but the -usecustomedid command coupled with -refresh does seem to reset the value, it’s just not usable because of the Extension blocks being reset to the default values.

[Rataplan626]

@trevorp Thanks again for the input.

but I wanted to report that on the NUC 11 on a different Dell U3014 monitor, everything works as expected with 0.15b5.

Hurray!  at least SOME success :-)

I also see that on the NUC, it does create a new entry ending in UID0 but the first part of the key matches the Dell monitor, whereas on the problem PC it does not.
e the registry exports, but they show the same, and this is pretty easy to digest.

Now that's what I saw as well when monitoring CRU, but it also does a RegSetValue on the monitors 'own' EDID value (ie. not in the EDID_OVERRIDE key).

@TitanGorilla, thanks for that eleborate post as well

Each time -refresh is run, the default extension block is reset.

That could be. Reason: when you start from scratch (ie. never ran CRU, or remove monitors / drivers and restart) you will probably not have a default extension block. But when you run CRU, it generates some stuff in the EDID_OVERRIDE key that's not there by default. At least on my systems, CRU 'generates' that default extension block, it's not there by default. This is on my laptop which never had any resolution set by either RatRefresh or CRU:


And using RatRefresh 0.15 without -usecustomedid, it will always use the EDID value in 'HKLM\SYSTEM\CurrentControlSet\Enum\DISPLAY\SDC424A\4&25831cb2&0&UID265988\Device Parameters' and then the EDID value, which I keep calling the monitors' own EDID, as that's were the 'default' EDID ends up. And again, when you DO use -usecustomedid, it uses the 0 value in EDID_OVERRIDE, and it should behave 100% identical to 0.11, which it does on my systems.

-usecustomedid with -refresh does set the new refresh rate value each time it's used.

You mean when you use -usecustomedid it actually works for you? If so, please report, as that would clear a lot of confusion for me. In your screenshot, I see the default extension block is actually there, so you probably had CRU to set a custom resolution to set 0.11 up, OR 0.15 with -usecustomedid? I would actually be happy if that worked, as, and sorry to repeat myself, 0.15 with -usecustomedid should functionally be the same as 0.11 with regards to the resulting regsitry, but that also means for now you need to setup thing by using CRU to setup one custom resolution, so a custom EDID value to reuse actually exists. If you use -usecustomedid but no custom EDID exists, it just uses the monitors original EDID value.

My goal is still to have RatRefresh work without the need for CRU, as I think that -setup parameter greatly improves usability for people that aren't as technical as you two. I have the sourcecode for CRU, but that's quite the thing in it's own But worst case I could use that to create the same 'Default extension block' as CRU does. Or at least understand WHAT it creates that for maybe.
I've not been feeling too well the last couple of days, the kids don't grant us a lot of sleep  but I want to work on it again in a couple of days.

[TitanGorilla]

I’m happy to help test to make RatRefresh the best it can be 😊 I know what you mean, I completely understand. There is definitely a lot going on with life that makes it hard to test and respond as often as I’d like. I’m satisfied with the way .11 works but it would be great to get the later versions working too. Definitely, no need to rush the development of it if you have limited free time. I can only imagine having kids would be to balance work and other demands of life and debugging RatRefresh in your free time. That would be great if there was a way for you to add a command to reset the default extension blocks, it seems to be what’s keeping later versions from working on my machine. It’s interesting your laptop doesn’t have any default extension blocks. I wonder if you were to use RatRefresh if it would set default extension blocks. It does seem like using -usecustomedid works to reset the refresh rate. Below are the steps I took to reset it and showing it refreshing the refresh rate after using -usecustomedid.


This is after first running -refresh with -usecustomedid. 57.777 is now showing in CRU.


The refresh rate is showing in CRU but still not selectable in Advanced display properties.


I deleted the default extension blocks before restarting my machine. If I don't delete the default extension blocks it seems to prevent it from showing the new refresh rate.



I restarted my machine, the new refresh rate from -usecustomedid is now selectable in Advanced display settings.

[Rataplan626]

Well, there's a few things again. What I see from your CRU screenshots is that you have multiple Detailed Resolutions setup, which is not where the tool is actually intended for - when you have only one and you reset the driver, that one resolution becomes your 'default' and hence your screen should be in the desired refresh rate without manually having to select it. Having said that, it should still work, but it probably won't automatically switch to the resolution set by RatRefresh.

Now, when you delete the Extension Block, what I see on my system is that in the EDID_OVERRIDE key, a value 1 is written, with only value 02 03 at the start, and at the end just the checksum. So if that's what's needed, it's easy to add. You can try v15 debug build 6 with parameter -removeextensionblock.

To be sure of everything, and rule other things out, I'd want to ask you again to remove monitors and video drivers from device manager and have them redetected. Then use ratrefresh -setup (ID's might have changed) and then

Code: [Select]

ratrefresh -refresh 59.150 -removeextensionblockand then check with https://testufo.com/refreshrate
In other words, how I want a new user to be able to use it Of course you can run CRU to see if the extension block is actually not available anymore now. If that works you're free to check with your multiple custom resolutions setup, and to see whether it's reflected in your NVidia panel as well.
[edit]
If it doesn't you can always try the 'old' way, create a custom resolution with CRU and use -usecustomedid and -removeextensionblock to try. But obviously I want it to work without the need of CRU.
[/edit]


By the way, I expect you need a restart of the video driver with either CRU or RatRefresh 0.11, in order for the new resolutions to show up in the NVidia panel?

If it still doesn't work, I'd like to see the difference in your registry when you remove the Extension Block from CRU. As said, on my systems I get a value 1 with data "02 03 00 00 00 ...... 00 00 FB". That's what I hardcoded now in order to remove the ExtensionBlock (which feels a bit weird to be honest, adding something to remove something).

Anyway, try and report :-)

[TitanGorilla]

It seems like the new -removeextensionblock parameter fixed the issue with the default extension blocks. If I run -refresh with the new -removeextensionblock it sets the new refresh rate. I didn't have to do much to get it working either. I re-installed Nvidia drivers with the DDU utility, I'm not sure if re-installing the drivers was even necessary. I ran the new 0.15b6 version with -setup and was able to run -refresh and -removeextensionblock with the new refresh rate. There were two refresh rates available to select, 60hz and the new one set. Once I selected the new refresh rate, I was able to set a new one as long as the -removerextensionblock was present. It seems to work every time, and the refresh rate is reflected on the refresh rate checker UFO test site. If I run -refresh without -removeextensionblock it would give me the same issue as before, it seems to always create default extension blocks, with the new refresh rate set being hidden. I'm not sure why it creates new refresh rate blocks for me, but I'm glad the new parameter seems to correct the issue! Below are screenshots of my results.

[Rataplan626]

Hey that is some good news! Thanks for reporting, happy it works. However, just yesterday I got hold of a system with an AMD gpu, which seems to have issues as well. So before releasing a final new version, I want to check that out as well. What I'm currently thinking of is this: I currently just pick the monitors EDID value, and change the first custom resolution pixelrate, but leave everything else in. For me (as used in an arcade cab) I don't want anything else than the resolution my screen is already at, but with another refresh rate. So maybe I should more or less just generate an empty EDID override key, with only that resolution in and nothing else.

I could at least make that an option I guess. I'll try to get that working.

Thanks for reporting again!

[Rataplan626]

Version 0.15b7

Guys, I did some more research on those Extension blocks. They might give some unexpected issues indeed. I still have two systems on which I occasionally have issues. One is my work NUC (intel) and one is a AMD system with three screens attached. Still working on what's wrong there.
Anyway, I added some fields that are reported with the monitor properties, like it tries to detect the connection used, might be handy to identify the correct display if multiple are used. But also, I now use the 'correct' way to make it use no extension blocks. Rather than what CRU actually does, which is create an empty extension block, there is a bit that can be set in the main EDID value, to disable extension blocks.

So, again, for those who have issues, try the link above. And for those that still have issues, please use device manager to remove BOTH all your monitors and all your display adapaters, and reboot , and DON'T use 'Scan for hardware changes' to redetect the hardware. After that run RatRefresh -setup, and then use RatRefresh -Refresh <something> -removeextensionblock
If your screen has extensionblocks, and you don't use -usecustomedid, you will have to use -removeextensionblock every time, as then the original EDID value has the 'use extension block' set to 1. Please don't use CRU before testing as that seems to mess up things.

And if it doens't work, please export the whole HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor ID> tree including subtrees, so I can see if it makes any sense. If feel it's giving less issues when I disable the use of extensionblocks period, so if that turns out to work better, I'll probably make that default.

[edit]
Meanwhile I've been browsing through the CRU source, and while that's written in Borland C++ or something, it's less difficult for me to read than I thought. The extended EDID seems to be read through API calls, which is only implemented for NVidia GPU's through nvapi.dll, and on AMD GPU's through atiadlxx.dll or atiadlxy.dll" if the first is not available. Intel is not implemented in CRU. I have a very old Zotac mini-pc, which has a AMD videocard of some sort. And sure enough, when I plugin the same Dell screen I have on my normal home-pc, it shows CTA-861 as extension, just as on your screenshot, whereas when I use the same screen on my Intel NUC (with Intel GPU of course) it just shows a 'default extension block'. So I now have another system I can test things on.
While I'm sure I'm able to impelement AMD / NVidia API calls, that would take time. And id it's needed I'll do it. But if it turns out RatRefresh's goal can be achieved without it, at this point I don't think I'll invest the time. We'll see :-)

[TitanGorilla]

I just wanted to add an update on the extension block issue that I noticed yesterday. I recently got a new 1440p 144hz monitor and ran into issues with it when using the new delete extension block parameter on my new monitor. On my older monitor, I don't think I needed to have the extension blocks present but it seems to be needed for HDMI 2.0 monitor functionality(higher refresh rate, HDR, etc.) I haven't had a chance to test your new release but just wanted to update you after realizing this. I noticed version .11 doesn't reset to a 'Default extension block', but keeps the original extension block. I think this is why it worked for .11 but is giving issues in later versions. I don't know if it's a CRU bug, but it won't display any other refresh rate to select in the display settings, if a new 'Default extension block' is set or overwrites the original extension block. It seems like one of the original resolutions/refresh rate values is being overwritten from the EDID in one of these original blocks, which might be why the default block is just a standard copy of the original but isn't modifiable. If the original extension block remains, there shouldn't be any issue. I tested just removing the detailed resolutions for the original extension block, and this seems to work. For some reason, later versions after .11 replace the original extension block with a 'Default extension block'. This seems to work to prevent issues with the monitor, but for some reason it won't let you see any other resolutions set. If you keep the original block there, with the data blocks present, but just delete the detailed resolutions, it seems to still keep the new refresh rate set. I haven't had a chance to test your new release, but if this hasn't been made, would it be possible to prevent RatRefresh from replacing the original extension block with a 'Default extension block' each time -refresh is run? Also, it might be a good idea to have a parameter or command added to delete all of the original extension blocks's detailed resolutions, but keep the extension block's data blocks. Maybe this or another parameter could globally delete all the refresh rates in CRU other than the new refresh rate set by RatRefresh, so only the new resolution set is selectable from the display settings. I'm not sure if there is a way to preserve the original extension block after it's deleted, but if it could, it might be useful to add some individual commands to delete all of the present refresh rates and resolutions, and maybe another command to restore them to the original value if possible. This might be useful in case people who don't have CRU want to reset to the original extension block and original settings before RatRefresh was used. It might be easy to just incorporate or call CRU's reset-all.exe file to reset to the original values. This probably won't work if CRU isn't installed though, but maybe similar functionality could be added that does something similar. The 'Default extension block' set seems to be useless for setting new refresh rates, since you can't seem to select any new refresh rates set from the display settings. Here are some screenshots of the original and default extension blocks, on both my old and new monitor.





After using -refresh with .11, the original extension block still remains.



Every time -refresh is run on later versions, it seems to delete the contents in extension blocks and overwrites with a 'Default extension block'. On my new monitor, it won't work without this Default extension block or the original extension block present, which makes sense, since they seem to be the same thing, but the Default extension block seems to have some issues. It seems the 'Default' can't be customized and there is also no way to go back to the original block, unless CRU is used to reset it. If it's possible to keep the original instead of the 'Default extension block' this might help with some of the issues from before.

 

[Rataplan626]

Well, again, you use CRU here which modifies and adds things to EDID. But still, even if you did, if you use RatRefresh -usecustomedid after using CRU, it will do the same as 0.11, namely only change byte 54 and 55 of the 0 value in the EDID_OVERRIDE key, and value 127 (the last one). 54 and 55 is the pixelclock in 10kHz units (reversed, because why take the easy road). Byte 127 is checksum, which must match else the value is ignored completely.

I don't have the luxury of a HDMI2 screen. I'm interested though in an export of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor instance> for that, to see if there's actually something different. For your info, if you completely reset things (remove from device manager, reboot) you can open the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor id>\Device Parameters key, there is an EDID value. If you open that, the next to last byte (ie. 126, start counting from 0) contains either 0 or 1 - 0 is no extension blocks, 1 is use extension blocks. When you use CRU to create custom resolutions, and there is an extension block active (even default counts), in the EDID_OVERRIDE key it'll create the 0 value (which is the regular EDID value) with bit 126 set to 1. And if that's 1, there will also be a registry value 1, which contains the extension blocks. When it's set to default, so far I've seen it then has value 02 03 00 00 00 00 ....... 00 and then the checksum.

So, if using extension block on a custom resolution, in EDID_OVERRIDE you'll have values 0 and 1. But I don't know where the extensionblocks would be stored when you DON'T use a custom resolution, i.e. your monitors own EDID in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor instance>\Device Parameters is still only 128bytes in total, and I've not seen another value in there. As far as others with the same question I've found, Windows only stores the first EDID block and not the extension blocks. If we need them for some monitors to work, I'll need to find a way to get them from the monitor. CRU can do it (or does it just make some extension block up?), and I have CRU's sources, so I might be able to figure that out, although it'll not be easy.

I tested just removing the detailed resolutions for the original extension block, and this seems to work. For some reason, later versions after .11 replace the original extension block with a 'Default extension block'. This seems to work to prevent issues with the monitor, but for some reason it won't let you see any other resolutions set.

Maybe I'm misunderstanding you, but isn't that exactly what we want? When I start a MAME game from my frontend, which has a certain rereshrate, it runs RatRefresh, and after disable / enable the display driver I am in that refresh rate. Without the need of manually switching to it. That's exactly the intention of the tool, to automate so your game runs at the exact speed it was intended for. It's NOT meant to add multiple resolutions with different refreshrates in order for them so show up in Windows. The deal (or at least my deal ) is to have only ONE resolution in there, so Windows HAS to use that. If you want to setup different ones, then CRU is your buddy, as that's much more versatile for that. Basically, sorry for repeating, RatRefresh changes the pixelclock (ie. byte 54 and 55) and the checksum, and stores that in the EDID_OVERRIDE value. All other options are for trying to get it to work in more configurations. But we should have the same expectation in mind else you might say 'doesn't work' but maybe it actually does

It seems the 'Default' can't be customized and there is also no way to go back to the original block, unless CRU is used to reset it. If it's possible to keep the original instead of the 'Default extension block' this might help with some of the issues from before.

The thing is the Extension block is not in registry. When you run CRU and save a resolution, it creates the EDID_OVERRIDE key and in your case has value 0 and 1, 0 beging the regular EDID block (with customized resolutions if any), and 1 with the extension block. If you remove the complete EDID_OVERRIDE key (ie, RatRefresh -remove would do that) it reverts to the original EDID, which is NEVER changed from RatRefresh. However, I have seen CRU change that, as per some procmon screenshots some posts above here. So that means, if CRU leaves the original EDID alone, removing the EDID_OVERRIDE key should reset everything back to normal.


So what I'm interested in, is a 'clean' registry export of your new monitor, after remove / reboot of everything. If possible the whole registry tree. There should be an EDID value in there. Then, use CRU and edit the default resolution, preferably only the refreshrate. Save that, and there should be a EDID_OVERRIDE key now, with values 0 and 1 (and who knows even more). I'm curious if that 1 value actually holds some data, or if it's just the default 'empty' one I've seen before. Please do an export of the whole monitor registry again, so I can also see if CRU modified your original EDID value.

[edit]
Looking through the CRU sources, I see it uses specific API calls for AMD and NVidia CPU's, but nothing for Intel. I have an old Zotac mini-pc, which has an AMD cpu. And sure enough when I connect the very same Dell monitors on it as I have on my home pc, it shows the CTA-861 extension block with some additional resolutions. Whereas my Intel NUC (with Intel GPU of course) just shows a 'default extension block'.
So I now have another system to test with. If it's really needed I'm sure I can implement the API calls, but I'd absoltely prefer not to do so if it's not needed for the goal of RatRefresh. So what I'll try is fiddle around with extension blocks without resolutions in it, so that way I expect Windows would just use the one resolution / refresh rate that's left.

No registry exports needed anymore for now, as I can do them myself which is obviously quicker. Still interested in answers to my other question - do we expect the same from RatRefresh? Stay tuned :-)

[edit2]
And I just confirmed this ATI machine behaves exactly as your machines do, it just stays at 59.950. So AMD and probably NVidia systems are the issue here. I'll try to figure it out

[TitanGorilla]

I might not have been clear in my description, but that would be ideal for it to only have one refresh available to be set, to have the monitor's refresh rate reset with RatRefresh through automation with a script to use for MAME. I was mainly just using CRU to see the changes after running RatRefresh, since the refresh rate didn't change.

It seems if the original extension block is there(not the 'Default extension block'), it will allow you to set the refresh rate. The 'Default extension block' seems to prevent you from setting the refresh rate that is set with RatRefresh. For some reason .11 doesn't seem to set a default block after running -refresh and the original extension block will remain after using -refresh. Later versions of RatRefresh(versions after .11) always seem to show a default block being set in CRU after running -refresh. Removing it through the -removeextensionblock seems to fix the issue on my older monitor, but on newer monitors it blacks out the screen, on restart the native monitor resolution is distorted as well. I think it needs an extension block with data block(s) set for HDMI 2.X.

Adaptive sync(g-sync or free-sync for Nvidia or AMD) might be a possibility for newer hardware. I'm planning on upgrading to a new PC soon with a g-sync compatible or freesync video card. Adaptive sync might fix the issue with the refresh rate for games in MAME that are natively below 60 hz(or the ones that are slightly above 60 like pac-man). It's still nice to use RatRefresh to set the monitor refresh rate to the exact refresh rate of the original arcade games. My current graphics card is too old for g-sync or freesync without a g-sync module monitor though so I can't see which gives better results. Definitely don't want you to go through all that work to fix this issue if the main use case for RatRefresh is for hardware not capable of adaptive sync. 

[Justin]

Just wanted to say that a simpler and cleaner way to obtain the refresh rates dynamically (from MAME only) would be to have your app send mame a request for the xml file corresponding to the specific rom about to be played.   I do this for my mame4to8 app (search my threads) which switches my motorized joystick restrictor plate  4/8 way as needed. 

You can prompt mame to generate a small xml for JUST the rom in question.  And then you can parse it and look for the refresh rate.

[Rataplan626]

Just wanted to say that a simpler and cleaner way to obtain the refresh rates dynamically (from MAME only) would be to have your app send mame a request for the xml file corresponding to the specific rom about to be played.   I do this for my mame4to8 app (search my threads) which switches my motorized joystick restrictor plate  4/8 way as needed. 

You can prompt mame to generate a small xml for JUST the rom in question.  And then you can parse it and look for the refresh rate.

Yes I know of that function. But there's two things; loading the 300+MB mame file is not the fasted on all machines, and besides RatRefresh is not just for mame. It could be used for other programs / emulators as well. Now I could still make some logic so it would use mame.exe when running for mame, which will be it's usage for most people, I reckon.


I've been very busy with work and life the last couple of weeks. I've got an AMD powered mini-pc on my desk now, which as stated has the same issue; it stays on the default refreshrate, even if the custom one IS added and actually available. I might have to use the API to switch resolutions. And I'm going to look into that, but it's gonna take a few more weeks I'm afraid.

[Justin]

No no, i don't think you read me correctly. You can have mame generate a very small xml for ONLY a single rom.    You can have ratrefresh  prompt mame to create the xml for the game that is about to be played .... 

[Rataplan626]

Yes I know :-) But the mame executable doesn't get any smaller from that :-) It's not the fastest to load, and considering most people have some old pc in their cabs, I made the decision years back to generate this small file. But as said, if people want it, I can implement it with an additional parameter, it's just a few lines of code.

[Justin]

Ok sounds good. I was referring to your comment about loading a 300mb file.  The single rom xml info file is a few kbytes at most

[Baldbull]

Hello!

I've recently found this tool and have been fighting it thus far...  FYI - I have a Makvision CRT and Nvidia GPU.

Initially, I downloaded 0.14 and had zero success.

After reading through this thread a few more times and downloading the latest beta, I made some progress... but the tool only seems to work 10% of the time?  Can't figure out why.  Timing issue?

I made progress after downloading CRU and creating a custom "dummy" resolution.  I use RatRefresh command-line, get the USB connect.. then USB disconnect sound.

The new refresh rate shows in Windows/Display and if I change it there, will always work... but like I said, the RatRefresh tool will only set this new refresh rate about 10% of the time.

Maybe I can find a tool like QRes that can support non-integer refresh rates and do a multi-step method?

Any ideas?

[Rataplan626]

There is still issues with AMD and NVidia gpu's because of how their drivers work. I'm working on a version that works with AMD, NVidia would be next. The issue is indeed that the new refreshrate IS registered, but not automatically selected. And I'll need to talk to the API for that. At least with AMD.
When you ran RatRefresh, does Windows show two 60Hz refreshrates in the display settings?

[Baldbull]

There is still issues with AMD and NVidia gpu's because of how their drivers work. I'm working on a version that works with AMD, NVidia would be next. The issue is indeed that the new refreshrate IS registered, but not automatically selected. And I'll need to talk to the API for that. At least with AMD.
When you ran RatRefresh, does Windows show two 60Hz refreshrates in the display settings?

No. Only 1.

I've identified a utility called nircmd which has a setdisplay option.  This successfully changes resolution, but only supports an integer value for refresh rate.  I also found another utility called SetResolution, with the same issue, though either should probably work for anything that does not round to 60.

Passing the appropriate refresh rate onto these utilities seems to be a viable, although clunky option.

[Rataplan626]

It's been a long while, but live struck me. I don't have any AMD or nVidia stuff anymore, so I can't troubleshoot or develop this any further. It seems to work fine for Intel iGPU, and I still use it on my cabs to great extent. I've had question from people using VRR and FreeSync with RatRefresh, but I don't have any of that fancy stuff so I don't know. I don't know if Mame has a implementation for such monitors to run at the correct rate, if not I still think RatRefresh might be beneficial as Mame can then sync to the set refresh rate.

Anyway, I think it's fair to conclude this tool is discontinued now. If there's any specifics I can help with, feel free to ask. AMD nVidia support is unlikely to ever get in because of lack of time and equipment.