mergedfb refresh rates

[Alex Deucher]

On 4/23/07, Dave Airlie <airlied at gmail.com> wrote:
> The mergedfb refresh rate calculation is still bogus and in fact randr
> is completely busted with the latest ATI driver, as I posted to the
> xorg list the way randr matches the metamodes also includes refresh
> rate matching which seems to be completely bogus..
>
> Can someone define what the refresh rate calculation should like, or
> revert the code back to generating the same values as the randr
> implementation does..
>

The problem is mergedfb is broken WRT to refresh rates, and I'm not
sure what a good work-around is.  The problem is you can have
metamodes that have the same screen size but differing refresh rates
on each head.  you need to make the metamodes unique or they will be
discarded by the server.  Take this example:

metamode0:
head0: 1024x768 at 60 and head1: 1024x768 at 85
metamode1:
head0: 1024x768 at 85 and head1: 1024x768 at 60
metamode2:
head0: 1024x768 at 60 and head1: 1024x768 at 60
metamode3:
head0: 1024x768 at 85 and head1: 1024x768 at 85

what would the metamodes be for this scenario?  The driver used to do
generate random unique numbers to try and keep each metamode unique.
However, this led to negative refresh rates in some situations which
caused problems with some utilities.  Henry committed a fix to keep
the numbers positive, but I suspect that may be what's causing the
problem now.  Either that or some new interaction with the randr1.2
code in the server.
See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=6966

Alex