2009/10/8 Matthias Hopf
I just found (by bisecting an issue that was extremely complex to reproduce) that - by accident - one of my commits was enabling power management by default, setting the engine clock to 1/2 of the default clock. *Always*.
Good news is that we haven't received many bug reports about engine stalls, so we can assume that setting the engine clock is working fine. At least as long as the engine is idle (which is the case on startup).
This could also explain a few cases where switching VTs during runtime made the system instable. When something was rendering during that time, the engine clock might have been changed underneath, and we don't wait correctly for a paused engine yet.
More importantly, DDC clock is tightly coupled with the engine clock, and if the engine clock is too low (relatively), DDC might cease to function. Which was exactly what I was seeing here.
So if you had issues with the modes of your monitor not being detected correctly lately, please retest with current git master. Chances are it just works (TM) now.
If you're using ForceLowPowerMode, you'll see that radeonhd uses a different clock now (the lowest known good one). On some cards this will be even lower than the previous default/2, on others this might be the default clock. If you want to go lower, use LowPowerModeEngineClock to set a lower one, and negate that number, in order to skip validation. E.g.
Option "ForceLowPowerMode" "on" Option "LowPowerModeEngineClock" "-200000"
Why did you change that to negative? Confusing users & breaking current xorg.configs. Just read value from xorg.conf and write it as negative in driver's variable. pm->variable = -xf86Get.... -- Rafał -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org