Main > Software Forum
[Discontinued][17-09-22] RatRefresh - refresh rate switcher, stops LCD tearing
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.
--- Quote ---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.
--- End quote ---
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 :)
--- Quote ---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.
--- End quote ---
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 :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version