Custom Resolution Utility (CRU)

[jael182]

(09-06-2024 04:38 AM)ToastyX Wrote:  

(09-06-2024 03:29 AM)jael182 Wrote:  I need some help. I have a TCL C855, and I use as my monitor. NVIDIA GPU using a HDMi 2.1.
My problem is, when I try to use the DSR feature, he uses the 4096x2160 resolution with 24hz to multiple, and downsample to it.
I want the driver to use the 3840x2160 120hz.

I downloaded the CRU, and deleted the 4096x2160 24hz in the CTA-861 Extension Block. But this resolution still appears on the Nvidia Control Panel.

What else do I need to do, to complete erase this resolution?

Did you delete it from the HDMI data block as well?

It only appears in the HDMI datablock. As you can see in the images

https://prnt.sc/SOugbVI9u9zX

https://prnt.sc/l4D_lt8TF0Wc

---

ok, i found it. It works now. Thanks

[Sunspark]

Hi, I have a modelines timing related question.. I am wondering how manufacturers decide together what timings to use and why it is not a "perfect" number?

My monitor is a non-standard resolution, so when that first came out, the included EDID for it from Samsung and Dell used 59.90873 Hz with a pixel clock of 156.75. Yesterday, I decided to look at the EDIDs for all monitors using that resolution from different manufacturers (thankfully not many) and it was interesting, the ones that came later in various sizes, the timing they all chose was 59.998565 Hz with a pixel clock of 157.250.

What I don't understand is, why didn't they just make this change or that change and end up with a perfect 60.000 Hz and still be within the pixel clock specification? You can easily get 60.000 using CRU and other tools.

I have observed that different timings do affect the "stability" of the picture in that some make the backlight look more stable than others, but then there is a subtle gamma or colour difference (this is all with digital connections). That could be the reason, but I doubt they were looking that closely at pictures and video.

So I am wondering how manufacturers decide what timings to use.. standards documents you might say, but this is a non-standard resolution.. the last time it actually appeared in a document was in an old VESA specification years ago and that one actually was 60.000.

I suppose I am wondering why they originally introduced it with 59.90873.. is it that they didn't know what they were doing back then without calculators, or there was an unknown reason for it which was forgotten?

---

I am also wondering if "Range Limits" in an EDID are actually real on a digital display.

My monitor's EDID says "Range limits: 56-85 Hz, 30-92 kHz, 170 MHz".

It makes no sense to me, because by that logic it can't even do 50 Hz which would be the European video specification when it very obviously can..

Yet, I routinely use 23.976 Hz with it all the time with no issues. So does this mean I am wildly overclocking the monitor, or it is internally converting it upward into 60 Hz? Or is it that the range limits are arbitrary and don't make sense on a digital connection which probably cares more about pixel clock?

[ToastyX]

(09-06-2024 03:27 PM)Sunspark Wrote:  Hi, I have a modelines timing related question.. I am wondering how manufacturers decide together what timings to use and why it is not a "perfect" number?

My monitor is a non-standard resolution, so when that first came out, the included EDID for it from Samsung and Dell used 59.90873 Hz with a pixel clock of 156.75. Yesterday, I decided to look at the EDIDs for all monitors using that resolution from different manufacturers (thankfully not many) and it was interesting, the ones that came later in various sizes, the timing they all chose was 59.998565 Hz with a pixel clock of 157.250.

What I don't understand is, why didn't they just make this change or that change and end up with a perfect 60.000 Hz and still be within the pixel clock specification? You can easily get 60.000 using CRU and other tools.

I have observed that different timings do affect the "stability" of the picture in that some make the backlight look more stable than others, but then there is a subtle gamma or colour difference (this is all with digital connections). That could be the reason, but I doubt they were looking that closely at pictures and video.

So I am wondering how manufacturers decide what timings to use.. standards documents you might say, but this is a non-standard resolution.. the last time it actually appeared in a document was in an old VESA specification years ago and that one actually was 60.000.

I suppose I am wondering why they originally introduced it with 59.90873.. is it that they didn't know what they were doing back then without calculators, or there was an unknown reason for it which was forgotten?

---

I am also wondering if "Range Limits" in an EDID are actually real on a digital display.

My monitor's EDID says "Range limits: 56-85 Hz, 30-92 kHz, 170 MHz".

It makes no sense to me, because by that logic it can't even do 50 Hz which would be the European video specification when it very obviously can..

Yet, I routinely use 23.976 Hz with it all the time with no issues. So does this mean I am wildly overclocking the monitor, or it is internally converting it upward into 60 Hz? Or is it that the range limits are arbitrary and don't make sense on a digital connection which probably cares more about pixel clock?

There are several different standards with different guidelines. CVT and GTF are general formulas that can be used with any resolution. The CVT standard says to round the pixel clock down to 0.25 MHz multiples. CVT-RB version 2 changed that to 0.001 MHz multiples. CRU doesn't round down because I don't want to limit the possible refresh rates, and I want the entered refresh rate to be a minimum, so it rounds up to the next possible pixel clock value. They certainly could make it exactly 60 Hz like CRU does with the "Exact" option, but they are just following standards. The range limits are just what the manufacturer says the monitor officially supports, but that doesn't mean the monitor can't do other refresh rates.

[Sunspark]

Thanks, I am curious to know more about these numbers.. it is not important, just curious.

CRU Exact:
2048 48 32 32
1152 3 5 90

VESA DMT Page 98:
2048 26 80 96
1152 1 3 44

Top makes 60.000 Hz, 75 kHz and a pixel clock of 162.00. Bottom makes 60.000 Hz, 72 kHz and a pixel clock of 162.00.

The difference is 3 kHz of horizontal frequency.. when I look at the numbers above, it basically looks like CRU Exact roughly doubles the vertical values but not the horizontal, as compared to the other set, while VESA's DMT does the opposite, doubles the horizontal but not the vertical.

It's strange because the horizontal blanking interval in CRU Exact is smaller but greater vertical blanking, yet the horizontal bandwidth needed is greater. I wonder how they decided in 2008 that these are the values they would go with for this version of a modeline.

I also wonder between the two which is considered to be "better" for the video card and the display to manage. I'm thinking maybe the 72 kHz one because it has the same pixel clock but doesn't have to scan as much?

[ToastyX]

(09-06-2024 08:12 PM)Sunspark Wrote:  Thanks, I am curious to know more about these numbers.. it is not important, just curious.

CRU Exact:
2048 48 32 32
1152 3 5 90

VESA DMT Page 98:
2048 26 80 96
1152 1 3 44

Top makes 60.000 Hz, 75 kHz and a pixel clock of 162.00. Bottom makes 60.000 Hz, 72 kHz and a pixel clock of 162.00.

The difference is 3 kHz of horizontal frequency.. when I look at the numbers above, it basically looks like CRU Exact roughly doubles the vertical values but not the horizontal, as compared to the other set, while VESA's DMT does the opposite, doubles the horizontal but not the vertical.

It's strange because the horizontal blanking interval in CRU Exact is smaller but greater vertical blanking, yet the horizontal bandwidth needed is greater. I wonder how they decided in 2008 that these are the values they would go with for this version of a modeline.

I also wonder between the two which is considered to be "better" for the video card and the display to manage. I'm thinking maybe the 72 kHz one because it has the same pixel clock but doesn't have to scan as much?

CRU "Exact" is based on CVT-RB with the horizontal and vertical totals rounded to multiples of 80 (H) and 125 (V) because that always produces exact refresh rates with two decimal places available for the pixel clock. DMT timings that existed before the CVT standard tend to be arbitrary, but 2048x1152 came in late when CVT-RB was already being widely used, so I don't know why they did this resolution differently.

The DMT timing for 2048x1152 @ 60 Hz is unusual because horizontal values are usually multiples of 8 but this one has 26 for the front porch. I don't know the reasoning behind this other than maybe they were also going for multiples of 80 and 125 to make it exact, but they did it backwards and did 125 and 80 instead. To me it makes more sense to do 80 on the horizontal side because that's a multiple of 8, and for most other resolutions, CVT-RB's horizontal total is already a multiple of 80, but with 2048, this needed to be adjusted. Really it doesn't matter because digital displays should be able to handle any timing as long as the blanking periods are long enough.

Another consideration is HDMI transmits audio during the horizontal blanking period, so maybe they favored a higher horizontal blanking for that reason while also keeping the vertical blanking low enough to fit within the 165 MHz pixel clock limit for single-link DVI and old versions of HDMI. CTA has a new standard called OVT that isn't widely used yet which factors this into account, but it requires three decimal places for the pixel clock to produce exact refresh rates, so it can only be used with DisplayID detailed resolutions, which they also added as a CTA data block.

[Sunspark]

This makes sense, thank you for the insights!

I was playing with the OVT online calculator.. I don't think my setup liked the values it generated very much. What didn't work out at all, was the new CVT-RB3 one.. I tried the spreadsheet for fun which has it and the output was bad. Image was shifted to the side, etc. Tried a different combination of settings because it supports early vsync, different vblanks, etc. got a blank screen. This is one that I think might be more dependent on hardware support. Mine can't use RB3 unless there is an option combo I didn't try that would have fixed the problems.

3 decimal places for the pixel clock does work with xrandr in Linux for all timings. I was experimenting with it to see how close to 23.97602 I could get with a resolution of 1920x1080. 23.97606 is the closest you can get with the usual gtf, cvt formulas, but hardware might not like it as much as others.. the CTA modeline is 23.97608 and for Intel igpus, 23.9761 works well.

[peter4536]

hi,

when trying to copy my detailed res in the extension block it only shows my monitor with 200 hz instead of 240?

[ToastyX]

(09-07-2024 02:35 AM)peter4536 Wrote:  when trying to copy my detailed res in the extension block it only shows my monitor with 200 hz instead of 240?

What's in the main window?

[peter4536]

(09-07-2024 04:52 AM)ToastyX Wrote:  

(09-07-2024 02:35 AM)peter4536 Wrote:  when trying to copy my detailed res in the extension block it only shows my monitor with 200 hz instead of 240?

What's in the main window?

this

[ToastyX]

(09-07-2024 06:09 AM)peter4536 Wrote:  this

That's not the same monitor.