mergedfb refresh rates

[Henry Zhao]

 > 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

There are 3 versions under old randr,

(1)
    if (!(mode->VRefresh))
         mode->VRefresh = mode->Clock * 1000.0 / mode->HTotal /
         mode->VTotal;

(2)
/* 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 >> 

          + j->HTotal);
     mode->Clock ^= ((i->VTotal << 19) | (j->VTotal << 3));

(3)
     mode->VRefresh = (float)((i->Clock * 1000.0 / i->HTotal / i->VTotal)
          * 100 + (j->Clock * 1000.0 / j->HTotal / j->VTotal));

(1) can't distinguish metamodes having same refresh rates on primary
     head, In the example above, there will be only two metamodes with
     refresh rates 60 and 85 respectively.

(2) can distinguish metamodes having same refresh rates on primary, but
     results in negative refresh rates.

(3) can distinguish metamodes having same refresh rates on primary with
     a somewhat meaning reading. In the example above, there will be four
     metamodes with refresh rates 6085, 8560, 6060 and 8585 respectively.
     This is the current code.

> 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

The new randr (1.2) is capable of handling multiple outputs, and should
have a proper way of dealing this.

-Henry