https://bugs.freedesktop.org/show_bug.cgi?id=48772 --- Comment #4 from Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxx> 2012-04-16 08:49:59 PDT --- (In reply to comment #3) > (In reply to comment #2) > > radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the > > frequency between screen blackouts, but my sample size is small and randomness > > of the timings makes me uneasy to claim so yet. Would it make sense for it to > > have such effect? > > > > Sure. Setting that option sets the display priority in the memory controller > to the highest possible level. If the MC is still having problems keeping up, > it may be that your system can't handle a monitor that big. > > Alternatively, your monitor may not like the set of pll dividers selected by > the driver in this case or spread spectrum settings. You might try setting the > RADEON_PLL_PREFER_MINM_OVER_MAXP or RADEON_PLL_USE_FRAC_FB_DIV pll flags in > atombios_adjust_pll(). I'll have a look. > What link speed and number of lanes are being used for that mode? Does the > monitor support downspread? Easy there :), this whole area is very new to me. "Last week" I figured out some things about connector probing, anything on top of that still needs to be learned. > Does the proprietary driver work ok with that monitor? I can and will try. > > Is testing with tiling disabled relevant given the problem happens also without > > X running? > > That should be equivalent. Not sure I understand what do you mean by this? -- 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
