mergedfb refresh rates

Dave Airlie airlied at
Tue Apr 24 14:22:36 PDT 2007

> > I suspect it is due to the new compat randr code in the server which
> > seems to work out the refresh rate itself.. I'm not sure if the old
> > randr1.0 used to this or just passed through the refresh rate from the
> > driver..
> The refresh used to come from the driver. Now the server takes the
> refresh provided by the driver and computes a dot clock to construct a
> mode line. Then it takes those mode lines and back-computes the refresh
> value when a 1.0 client requests the old information.
> At least the latter part of this process works as 1.0 clients get valid
> information from a new server...
> I'll bet something is messed up in RROldModeAdd.

This really breaks the hacks that radeon mergedfb does, the new randr
doesn't pass refresh over the wire, when using old randr 1.0
driver/client on top of a randr-1.2 server the refresh rate is now
calculated by the DIX randr code as opposed to using what the driver
gave it which is what happened with the old DIX code pre randr-1.2

I'm not sure I can see any path out of the mess except making radeon
agree with randr or somehow hooking the refresh rate calculation out
of the DIX to the DDX so it can use the value from the modeline and
not a calculated value..


More information about the xorg-driver-ati mailing list