https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #15 from Luc Verhaegen <libv@xxxxxxxxx> 2012-04-19 06:45:19 PDT --- Alex, i thi(In reply to comment #14) > > As I said before some monitors are really picky about the clocks they get. The > pixel clock is generated from a reference clock and a set of dividers. In some > cases it's not possible to get exactly the pixel clock of the mode, so the > driver gets as close as possible. The two clocks produced are 148.43 Mhz and > 148.57 Mhz. Both are within 0.07 Mhz of the actual clock. Some monitors don't > like clocks that are slightly lower, others don't like clocks that are slightly > higher, others don't care. In some cases you even have monitors that don't > like certain divider combinations that produce the exact same pixel clock. As > you can see from comment 11, even your own monitor is happy and not happy with > the same pixel clock depending on the connection. > > I'd be leery of changing the pll flags without a lot of thorough testing since > these change may break certain modes on other monitors. Did you try > RADEON_PLL_USE_FRAC_FB_DIV? It should help the driver get closer to the actual > pixel clock by allowing a finer grained fb divider, but once again, some > monitors are picky about certain divider combinations. I'd be more inclined to > add this flag than the MINM_OVER_MAXP flag however. Err, Alex, i think that it is the display engine, for a particular version and process, that has issues with certain divider combinations which should theoretically produce the same pixel clock, not the monitor. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
