Bug 10205 - Radeon driver's own mode validation code does not work properly
Summary: Radeon driver's own mode validation code does not work properly
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.2 (2007.02)
Hardware: All All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-06 17:29 UTC by henry.zhao@oracle.com
Modified: 2009-04-03 01:25 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch to fix the problem (2.60 KB, patch)
2007-03-09 15:13 UTC, henry.zhao@oracle.com
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description henry.zhao@oracle.com 2007-03-06 17:29:19 UTC
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
    clock rate. 
    
(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.
Comment 1 Roland Scheidegger 2007-03-07 03:47:06 UTC
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...
Comment 2 henry.zhao@oracle.com 2007-03-09 15:13:19 UTC
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 
    database search.
Comment 3 Tom Horsley 2007-11-17 15:15:24 UTC
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).
Comment 4 Alex Deucher 2007-11-18 00:52:02 UTC
(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:
http://www.intellinuxgraphics.com/dualhead.html

Comment 5 Tom Horsley 2007-11-18 04:44:28 UTC
>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 :-).
Comment 6 Alex Deucher 2008-12-02 23:50:28 UTC
this should be working properly in newer versions of the driver.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.