ATI Drivers report bogus dot_clock to xvidtune

[Alex Deucher]

On 3/29/06, Egbert Eich <eich at suse.de> wrote:
> Alex Deucher writes:
>  >
>  > 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.
>  >
>
> I came across a similar problem in randr. It turned out that this really
> ugly hack in radeon_mergefb.c:
>
>      /* 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));
>
>
> caused the problem.
> I'm not sure if anyone but the author knows what it is good for.
> It's not unlikely that the problem with xvidtune is also caused by
> this.

How would you propose we handle having 2 heads with different timings
be handled by one screen in a reasonable fashion?  Unfortunately,
mergedfb is a hack.  The X driver infrastructure was not built to
handle multiple crtcs with one instance of the driver.  If you have
one head at 1024x768 at 60 and the other at 1280x1024 at 85 what should we
set the "meta" clock to?  Also we want to allow you to have another
metamode of 1024x768 at 60 and 1280x1024 at 75 and not have the mode parser
throw it out. Then throw in crtc orientations (left, right, clone).

Alex

>
> Cheers,
>         Egbert.
>