Custom Resolution Utility (CRU)

[ToastyX]

(07-07-2022 05:36 PM)Nintendo Maniac 64 Wrote:  Just a simple question - how is the value for the exact refresh rate rounded in CRU?

Basically I noticed that sometimes mpv "Display FPS" will exactly match that CRU described including the three decimal places (e.g. both saying 72.000) but, for other refresh rates/resolutions, CRU will list as being exactly 0.001 Hz less, e.g. CRU stating that a refresh rate is 75.000Hz but mpv listing it as 75.001

I don't suppose this means that CRU always just rounds down, e.g. 75.00064Hz is listed as 75.000 in CRU?

(it may be worth mentioning that I'm actually using the Linux version of mpv; I've discovered that CRU running through WINE is quite useful on Linux for calculating much more exact refresh rates since the normal "cvt" command on Linux generates modes that are not all that exact, e.g. 74.857 rather than the 75.00Hz that it the cvt command claims - for this reason I don't suppose there's a way to have CRU directly output an xorg/xrandr-compatible modeline rather than what I've been doing of manually adding the corresponding CRU values together to essentially manually create a custom modeline?)

It's truncated (rounded down). This is intentional because I wanted to make sure 60.000 Hz means it's at least 60 Hz and not something like 59.9995 Hz. I thought about changing the actual value to conventional rounding, but then there would be a mismatch with the value in the text box, which is meant to be a minimum, so the text box would still have to be rounded down to produce the same actual value. CRU doesn't currently save the entered value because only the actual value based on the pixel clock is in the EDID, so it generates an entered value when editing an existing resolution. I want to make CRU 2.0 preserve the entered values and timing option to make it less confusing, so I might change the rounding then.

The cvt program rounds the pixel clock down to a multiple of 0.25 MHz because that's what the CVT standard says to do. I chose to ignore that part for CRU because I wanted more precision.

I also wanted to make it possible to export modelines to a file, but this is too complicated to implement with the current design of CRU because detailed resolutions can be in several places with different types of extension blocks. CRU 2.0 will make this much easier to implement because it will be able to consolidate all the resolutions in one list. I also thought about making the "Copy" button put the modeline in the clipboard, but I wasn't sure how useful that would be for a Windows program.