Custom Resolution Utility (CRU)

[Haemato]

(08-01-2015 11:16 PM)ToastyX Wrote:  I doubt that's the problem. The monitor range limits descriptor is not required, and that information is not used for anything as far as I have seen. CRU does not include one because it would use up a detailed resolution slot, and it could interfere with custom resolutions if the driver actually did use that information.

I don't know what timing parameters you used, but if the pixel clock is not greater than 165 MHz, then there shouldn't be any issues with HDMI. Otherwise, you need to add an HDMI support data block in the extension block for the driver to accept higher pixel clocks unless you're using the pixel clock patcher. Make sure to run reset-all.exe if you're not using EDID overrides anymore. That will also reset the Windows screen resolution settings just in case it's stuck on some other unsupported resolution.

According to the Enhanced EDID VESA spec it is required. Specifically states that "A Monitor Range Limits Descriptor must be provided" under section 3.10. A Monitor name descriptor is required as well. Earlier versions of the spec didn't require this (prior to 1.3) so hosts can expect to run into this scenario. It's possible that nvidia is doing a strict interpretation of the spec and thus failing to parse the EDID. I'll know more on Tuesday (or earlier if I get off my ass and write a program to do the i2c writes myself).

As for the detailed timing I'm doing, it's simply the VESA standard 1280x800p120 with reduced blanking. Pixel clock is 146.25MHz so it's well under the 165MHz limit. It works when I use an EDID override and like I said the interceptor blocks work fine with my old Crossfire R9 290 setup (I did a clean driver install after DDU and the projectors all came up at 1280x800p120 immediately). But as soon as the nvidia drivers are installed the 980ti fails to output any video if the interceptors are present. More debugging to do ...

Will respond to PM after a nap - was up too late last night.