ATI Drivers report bogus dot_clock to xvidtune
Roland Scheidegger
rscheidegger_lists at hispeed.ch
Tue Mar 28 14:02:58 PST 2006
Alex Deucher wrote:
> On 28 Mar 2006 15:55:47 -0500, Greg Stark <gsstark at mit.edu> wrote:
>> "Alex Deucher" <alexdeucher at gmail.com> writes:
>>
>>> On 3/28/06, Roland Scheidegger <rscheidegger_lists at hispeed.ch>
>>> wrote:
>>>
>>> I also don't see how the dotclock would be of any use for vblank,
>>> but I suspect you are seeing a limitation of mergedfb. Mergedfb
>>> is basically a hack to treat 2 crtcs as a single screen. since
>>> you have two crtcs with different timings there's no way to know
>>> which dotclock or refresh rate, etc. is relevant (since they both
>>> are). Hence you end up with some weirdness for certain fields.
>>> Disable mergedfb if you want relevant numbers for those fields.
>> Yes I expect it's caused by mergedfb. I suspect what's happening is
>> that it's calculating the dot clock based on the refresh rate and
>> the combined desktop size. And it's overflowing somewhere. Though
>> I'm stumped where since it ought not be overflowing a 32-bit
>> integer. Perhaps it's doing some of the math in 16-bit integers?
>
> IIRC, it doesn't do anything special so you get random garbage.
Not quite. It's not an overflow but not quite random neither. There is
this lovely code which seems to be responsible for this:
/* Provide a sophisticated fake DotClock in order to trick the vidmode
* extension to allow selecting among a number of modes whose merged result
* looks identical but consists of different modes for CRT1 and CRT2
*/
mode->Clock = (((i->Clock >> 3) + i->HTotal) << 16) | ((j->Clock >>
2) + j->HTotal);
mode->Clock ^= ((i->VTotal << 19) | (j->VTotal << 3));
(the XF86VidModeModeLine call you used seems to return mode->Clock
somewhere down the road).
>> It calculates the refresh rate and then I guess it tries to lock
>> the output frame rate to the refresh rate. Ie, there's no need to
>> output frames faster than the refresh rate.
Ah you can't actually query the refresh rate directly and need to
calculate it based on all other parameters? Hmm yes that's not going to
work. Looks like a design flaw of how mergedfb works.
Roland
More information about the xorg
mailing list