madshi

ADL ModeTimingOverride bugs

Discussion created by madshi on Oct 1, 2010
Latest reply on Jan 30, 2012 by terence_13
uses different timings than asked for

XPSP3 32bit, HD 3850, Catalyst 10.9

The ADL ModeTimingOverride APIs *appear* to work just fine. Meaning, I can set timing overrides, they are accepted, and they are enumerated exactly as I set them. Unfortunately, it's rather rare that a custom timing mode is actually *applied* as it was specified. Some examples:

(1) Standard CEC 1080p60 timing (hTotal 2200, hDisplay 1920, hFrontPorch 88, hSyncWidth 44, hBackPorch 148; vTotal 1125, vFrontPorch 4, vSyncWidth 5, vBackPorch 36, pixelClock 14850). This one works just fine. The driver sets exactly the values I specified.

(2) Standard CEC 1080p60 timing with small modifications, e.g. vTotal set to 1126 or 1127 instead of 1125. What the driver actually sets is *very* different: (hTotal 2072, hDisplay 1920, hFrontPorch 32, hSyncWidth 28, hBackPorch 92; pixelClock 13950).

And this happens all the time. The driver appears to "like" some timing combinations, which are then applied correctly, but most custom timings are totally reinterpreted by the driver, which usually results in my screen going black, because it doesn't accept the funny timings set by the driver.

For people trying to reproduce this problem, simply start with the standard 1080p60 timings listed above, then slightly modify one timing parameter at a time. E.g. try increasing pixelClock or hTotal or vTotal by 1 or 2. You can verify what the driver really applies with PowerStrip (won't work for 5xxx cards, because PowerStrip doesn't support them).

BTW, the pixel clock adjustment steps are VERY coarse. It's really hard to hit target refresh rates like 24/1.001 or 59/1.001 this way. The pixel clock should be adjustable in much finer steps...

Outcomes