| Summary: | Radeon driver's own mode validation code does not work properly | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | henry.zhao <henry.zhao> | ||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | horsley1953 | ||||
| Version: | 7.2 (2007.02) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
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 database search. 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: http://www.intellinuxgraphics.com/dualhead.html >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. |
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.
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.