Radeon driver uses its own mode validation code when the monitor is LCD/DFP.
The code assumes the existance of EDID modes, and adds modes in all sectors
(detailed, established and standard) to the mode database and sort them. For
modes without timing data (established and standard), it picks a mode of the
same size with highest clock rate from default VESA modeline database. The
code used in this process has two problems:
(1) It does not process user defined modelines (with config file) properly.
(2) It does not give priority to EDID mode from detailed timing sector. If
a mode exits both in EDID and VESA database, it picks one with higher
(3) VESA modeline database is organized such that double scan lines are
inserted every another line. In VESA modeline database search, the code
uses p->next->next to skip double scan line, which does not work
correctly when user defined modes are added to the database.
There is a lot more wrong with radeon mode validation than that. For instance, all lower resolutions will always use on-chip scaling (RMX) for the digital output. Worse, it's always using fit-to-screen, if you ever tried to upscale a 5:4 resolution on a 16:10 panel you know you don't want that. Ideally, it should be possible to disable RMX (note some panels may not have their own scaler and need it), and rmx should be configurable so it offers at least the "common" options (no scaling, scale with aspect ratio, scale to fit). I think the chip could handle that, actually once tried it but failed (not sure but I think you'd need to program overscan correctly for that). A hack to disable RMX OTOH (and the safeguards for not using custom resolutions) is easy and useful, all decent panels (well those with scalers anyway) let you choose one of the 3 scaling methods, and if it blows up your panel be glad that you got rid of this piece of crap for free...
Created attachment 9059 [details] [review]
Patch to fix the problem
This patch fixes the problems reported in description field.
(1) Improve sorting algorithm to re-arrange priorities as below:
User defined modes
EDID modes in detailed timing sector
Higher clock rate
(2) Use if (p->Flags & V_DBLSCAN) instead of p = p->next->next
structure to skip double scan modes in VESA modeline
I can certainly confirm that xorg-x11-drv-ati-6.7.195-3.fc8 utterly
ignores any attempt I make to manually specify a mode line. I was
able (by hook or by crook) to do it in Fedora 7 with older driver
(after navigating maze of twisty xorg.conf options, all different),
but it seems utterly impossible with latest driver in fedora 8.
(Which is unfortunate since the EDID specified one doesn't actually
work correctly with my card and monitor combo, but a manually
hacked one at slightly less than 60HZ works perfectly).
(In reply to comment #3)
> I can certainly confirm that xorg-x11-drv-ati-6.7.195-3.fc8 utterly
> ignores any attempt I make to manually specify a mode line. I was
> able (by hook or by crook) to do it in Fedora 7 with older driver
> (after navigating maze of twisty xorg.conf options, all different),
> but it seems utterly impossible with latest driver in fedora 8.
> (Which is unfortunate since the EDID specified one doesn't actually
> work correctly with my card and monitor combo, but a manually
> hacked one at slightly less than 60HZ works perfectly).
you can add them at run time using xrandr:
xrandr --newmode <modeline>
xrandr --addmode DVI-0 <newmode>
see xrandr --help for more.
you can also add it to the config file as per these instructions:
>you can add them at run time using xrandr:
>xrandr --newmode <modeline>
>xrandr --addmode DVI-0 <newmode>
>see xrandr --help for more.
A good suggestion, but it also apparently doesn't work (in fact, even
ignoring my mode line, I can't make it switch to any of the other
modes it already has in its list, though I can make it switch
other things, so I apparently did decrypt the xrandr man page :-).
this should be working properly in newer versions of the driver.