(04-11-2025 07:07 PM)LGBoy Wrote: [ -> ]I did what you suggested, deleted several 3840x2160 resolutions under TV resolutions and 3x 3840x2160 under HDMI Support. After restart I've got this in NV control panel (1 in attachment) - 3840x2160 was gone and 3824x2151 was promoted to native res, but only custom 3824x2151 resolution was looking ok (and even there it wasn't possible to select 10-bit color depth, only 8-bit).
Native 3824x2151 was blurry as if it was upscaled from lower res and it was also limited to 60Hz (2 in attachment). When I enabled DLDSR, new 5736x3227 res was created and it also looked blurry as "native" 3824x2151 and it was also limited to 60Hz. Any idea what else could I try ?
You need to adjust the scaling in the TV's settings to "just scan" instead of upscaling.
Quote:You need to adjust the scaling in the TV's settings to "just scan" instead of upscaling.
Just scan is greyed out but set to On, in TV's settings.
I plan to upgrade soon to Win 11 and I will try this again once I do. Maybe I will have more luck there. Thank you.
(04-12-2025 05:58 PM)LGBoy Wrote: [ -> ]Quote:You need to adjust the scaling in the TV's settings to "just scan" instead of upscaling.
Just scan is greyed out but set to On, in TV's settings.
I plan to upgrade soon to Win 11 and I will try this again once I do. Maybe I will have more luck there. Thank you.
Windows 11 wouldn't make a difference. The native resolution is always sent to the TV, so the TV is the one doing the upscaling. You need to find a way to make the TV not upscale. The "just scan" option should not upscale, and if it's not available, then some other setting is causing it to be disabled.
The custom resolution you created in the NVIDIA control panel must have been a GPU-scaled resolution because if it were sent to the TV, the behavior would be the same as with CRU. When you create a custom resolution in the NVIDIA control panel, the active resolution is the resolution sent to the TV, not the display mode at the top, so if those are different, you end up with a GPU-scaled resolution.
(04-11-2025 03:16 AM)ToastyX Wrote: [ -> ]It doesn't need to be in the CTA-861 data block. In fact the monitor has a DisplayID 1.3 extension block with 5120x1440 @ 60 Hz and 120 Hz that CRU doesn't currently show because it doesn't support extension overrides yet. You can add those manually if you want them. For G-SYNC to work, you would need to edit the VRR range in the HDMI 2.1 data block in the CTA-861 extension block, but VRR seems to be disabled in the monitor because the range isn't set. I see a FreeSync data block, but NVIDIA doesn't support FreeSync.
Thank you for the response. I might have had Adaptive-sync disabled in the monitor's setting when I extracted the EDID table and that might be why it is not showing up. I extracted the EDID table again with adaptive-sync enabled, and have attached the output. CRU's GUI does show both Freesync and VRR ranges of 48-120 Hz in this case.
Anyway, I did further testing, and as you suggested, manually updated the Freesync and VRR ranges after adding the new resolution with 144 Hz refresh rates, and originally it seemed I was having success as Nvidia's driver did detect the monitor as Gsync-compatible with the new settings. I managed to get the monitor to run all the way up to 168 Hz, but I was experiencing sporadic picture glitches at 168 and 165 Hz (due to high pixel clock?), so I eventually settled for 150 Hz. Fast forward to the next morning when I had a very important interview, and low and behold, the monitor again got stuck on a black screen as soon as Windows finished loading. I luckily managed to recover by disconnecting the monitor and rebooting and going into windows using my TV and resetting the displays using CRU and went through the interview with some delay. The lesson I learned was to not tamper with my monitor's settings the night before an important interview...
Today I did more testing and it seems even though the new resolutions seem to work when I add them after having already logged into windows with the default monitor profile, as soon as I reboot and windows loading finishes, the monitor sits on an all-black screen at 3840x1080 @ 60 Hz resolution (per the OSD). This is clearly not a "no signal" scenario, but just black screen at that resolution as the monitor stays on and the OSD works. Even when I have my TV connected and enabled along with the monitor and power cycle, the TV goes into "no signal" mode while the monitor shows the black screen. It seems the video driver is crashing/not initializing at all in this case. I even tried removing all TV and standard resolutions identified by CRU for the monitor, but the result was the same after reboot. I only managed to get the monitor to survive rebooting once at 144 Hz, but after changing to 150 Hz and failing reboot and going back to 144 Hz, even 144 Hz didn't survive reboot anymore. At this point I just gave up and restored the original monitor settings; I am now hoping that MSI themselves will add support for 144 Hz through a firmware update as I requested through a support ticket a few days ago. This monitor seems to be too picky and I am starting to wish I had saved my money and bought the lower-end 144 Hz model as the 240 Hz mode on this one is unusable for me due to lack of support for DSR.
P.S. I understand that it is probably a lot of work, but do you have any plans to support "extension overrides" in CRU in the future?
Can we please get 4 digits of precision on the "Actual" refresh rate line?
The reason is that while windows displays 3 digits of precision, it's actually rounding up from 4 digits if the 4th digit is 5+... so the "actual" value displayed can differ from what windows considers it to be.
This 0.001 hz rounding actually matters, particularly in the case of Adaptive Vsync while also using a framerate limiter (although this isn't the only case).
For example, let's say you wiggle the values in CRU to get exactly 60.000 hz "actual" as displayed by CRU. And you set whatever framelimiter to exactly 60hz. And you enable Adaptive Vsync.
But due to rounding, windows is using 60.001 as the vertical refresh rate value. Well, Adaptive Vsync will simply fail to function -- vsync will never turn on.
I can work around this using simple math (add then divide by 2) after finding the highest and lowest back porch value, but it would be nice to just have 4 digits of precision displayed in the UI.
There are other edge cases where it also matters, but the above is probably the most common one?
(04-12-2025 07:25 PM)maftul Wrote: [ -> ]Thank you for the response. I might have had Adaptive-sync disabled in the monitor's setting when I extracted the EDID table and that might be why it is not showing up. I extracted the EDID table again with adaptive-sync enabled, and have attached the output. CRU's GUI does show both Freesync and VRR ranges of 48-120 Hz in this case.
Anyway, I did further testing, and as you suggested, manually updated the Freesync and VRR ranges after adding the new resolution with 144 Hz refresh rates, and originally it seemed I was having success as Nvidia's driver did detect the monitor as Gsync-compatible with the new settings. I managed to get the monitor to run all the way up to 168 Hz, but I was experiencing sporadic picture glitches at 168 and 165 Hz (due to high pixel clock?), so I eventually settled for 150 Hz. Fast forward to the next morning when I had a very important interview, and low and behold, the monitor again got stuck on a black screen as soon as Windows finished loading. I luckily managed to recover by disconnecting the monitor and rebooting and going into windows using my TV and resetting the displays using CRU and went through the interview with some delay. The lesson I learned was to not tamper with my monitor's settings the night before an important interview...
Today I did more testing and it seems even though the new resolutions seem to work when I add them after having already logged into windows with the default monitor profile, as soon as I reboot and windows loading finishes, the monitor sits on an all-black screen at 3840x1080 @ 60 Hz resolution (per the OSD). This is clearly not a "no signal" scenario, but just black screen at that resolution as the monitor stays on and the OSD works. Even when I have my TV connected and enabled along with the monitor and power cycle, the TV goes into "no signal" mode while the monitor shows the black screen. It seems the video driver is crashing/not initializing at all in this case. I even tried removing all TV and standard resolutions identified by CRU for the monitor, but the result was the same after reboot. I only managed to get the monitor to survive rebooting once at 144 Hz, but after changing to 150 Hz and failing reboot and going back to 144 Hz, even 144 Hz didn't survive reboot anymore. At this point I just gave up and restored the original monitor settings; I am now hoping that MSI themselves will add support for 144 Hz through a firmware update as I requested through a support ticket a few days ago. This monitor seems to be too picky and I am starting to wish I had saved my money and bought the lower-end 144 Hz model as the 240 Hz mode on this one is unusable for me due to lack of support for DSR.
P.S. I understand that it is probably a lot of work, but do you have any plans to support "extension overrides" in CRU in the future?
This is mentioned in the first post:
NVIDIA and multiple displays - ToastyX Wrote:NVIDIA's driver currently has a bug that can cause Windows to hang during boot when an EDID override is present with multiple displays connected. Workaround using scripts: https://www.monitortests.com/forum/Threa...wn-scripts
I also asked what happens if you disconnect the LG C1. If it works without the LG connected, then it's that driver bug.
Yes, I will be adding support for extension overrides soon.
(04-12-2025 01:59 PM)ToastyX Wrote: [ -> ] (04-11-2025 07:19 AM)ildottore101 Wrote: [ -> ]Thanks very much for the CRU Tool 
https://www.reddit.com/r/ultrawidemaster..._cru_tool/
You need to edit the existing 165 Hz in the DisplayID extension block, not add it in a new extension block.
Ok, i edited displayid 1.3 and got blackscreen again. On cta-861 i cant enable it becaus pixelclock turns red.
(04-12-2025 09:07 PM)ildottore101 Wrote: [ -> ]Ok, i edited displayid 1.3 and got blackscreen again. On cta-861 i cant enable it becaus pixelclock turns red.
That is supposed to work if the monitor supports the timing. Do you have any other monitors connected?
(04-12-2025 09:04 PM)daemonjax Wrote: [ -> ]Can we please get 4 digits of precision on the "Actual" refresh rate line?
The reason is that while windows displays 3 digits of precision, it's actually rounding up from 4 digits if the 4th digit is 5+... so the "actual" value displayed can differ from what windows considers it to be.
This 0.001 hz rounding actually matters.
The actual refresh rate is truncated and not rounded, so 100.0005 Hz will appear as 100.000 Hz in CRU but 100.001 Hz in Windows. Right now adding more digits might be a problem because I'm using fixed point decimal math to avoid floating point issues, so adding digits requires shifting all the math. I plan to support up to 6 digits with CRU 2.0, but that's still a while off.
The entered refresh rate is a minimum, so if you enter 100, it will pick the closest pixel clock that is at least 100 Hz. I also have "Exact" and "Exact reduced" timing calculators to give exact refresh rates. If you need more precise calculation for refresh rates, I also have this:
https://www.monitortests.com/pixelclock.php
(04-12-2025 09:04 PM)daemonjax Wrote: [ -> ]For example, let's say you wiggle the values in CRU to get exactly 60.000 hz "actual" as displayed by CRU. And you set whatever framelimiter to exactly 60hz. And you enable Adaptive Vsync.
But due to rounding, windows is using 60.001 as the vertical refresh rate value. Well, Adaptive Vsync will simply fail to function -- vsync will never turn on.
Missed this part because of the edit. I don't see why you would do that. VSync already limits the frame rate, but if you want to limit the frame rate for potentially smoother frame times, you need to set the limit slightly above the refresh rate because there is no guarantee that the frame limiting and the refresh rate will be synchronized perfectly. Nothing should be relying on refresh rates being exact because even if they are mathematically exact logically, they might not be measurably exact physically.