Bug 536686 - drv-radeon ignores Modelines and "preferred mode"
Summary: drv-radeon ignores Modelines and "preferred mode"
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 15
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Triaged
: 571050 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-10 22:38 UTC by Davide Repetto
Modified: 2018-04-11 11:41 UTC (History)
8 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2011-03-30 18:43:25 UTC


Attachments (Terms of Use)
output of dmesg (48.93 KB, text/plain)
2010-01-23 14:53 UTC, Seb
no flags Details
kernel & Xorg versions (142 bytes, text/plain)
2010-01-23 14:54 UTC, Seb
no flags Details
Xorg.log (45.73 KB, text/plain)
2010-01-23 14:55 UTC, Seb
no flags Details

Description Davide Repetto 2009-11-10 22:38:01 UTC
Description of problem:
=======================
Modelines and "preferred mode" in xorg.conf are ignored by this driver.
(The resolution though can be changed with xrandr after starting X.)

I'm testing on a Philips LCD (170C) 17 inches monitor and for this driver it is capable only of resolutions up to 800x600 while the monitor native resolution is 1280x1024 @60/75hz.

I "solved" the problem by running xrandr at the beginning of the gnome session, but it is of course a dirty hack.


Version-Release number of selected component (if applicable):
=============================================================
xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.i686


How reproducible:
=================
Always (with any xorg.conf hack I tried)

  

modified part of xorg.conf
==========================

[...OMISSIS...]

Section "Monitor"
    Identifier     "Monitor0"
    HorizSync       30.0 - 80.0
    VertRefresh     60.0 - 75.0
    Option         "DPMS"
    ModeLine       "Native_Res" 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync
    Option         "PreferredMode" "Native_Res"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        DefaultDepth     24
        Subsection "Display"
            Depth       24
            Modes       "Native_Res"
        EndSubsection
EndSection


Hardware
========
The card is a Radeon X1200 integrated in RS600 chipset on an Acer computer 
Unfortunately I have no more information on the hardware, since the customer rushed in amid the compilation of this ticket and took away the computer.
Sorry :(

Comment 1 Jérôme Glisse 2009-11-12 18:57:08 UTC
So you don't have the hw anymore ? You can get us full dmesg + xorg log ? Was it with KMS enabled ? Was is the output of:
rpm -q kernel xorg-x11-server-Xorg

Comment 2 Seb 2010-01-23 14:53:35 UTC
Created attachment 386336 [details]
output of dmesg

Comment 3 Seb 2010-01-23 14:54:41 UTC
Created attachment 386337 [details]
kernel & Xorg versions

Comment 4 Seb 2010-01-23 14:55:43 UTC
Created attachment 386338 [details]
Xorg.log

Comment 5 Seb 2010-01-23 15:13:41 UTC
(In reply to comment #1)
> So you don't have the hw anymore ? You can get us full dmesg + xorg log ? Was
> it with KMS enabled ? Was is the output of:
> rpm -q kernel xorg-x11-server-Xorg    

Hi Gerome,

I would laso like to report that xorg.conf ignores ModeLines.
This is true for the drivers 'nvidia' and 'vesa', also.

I am using a Samsung P55-pro T7500 Laptop with SXGA+ Display (1400x1050) and a GeForce 8600M GS.

I boot with the kernel option 'nomodeset' (grub.conf)
Also, I have all the framebuffers blacklisted in /etc/modprobe.d/blacklist.conf which I am not using except for the one explicitly mentioned in my xorg.conf.

Recently, the EDID-chip of the display can't be read back with monitor-EDID anymore. As the nvdia-driver depends on this info, my last resort was using ModeLines. But they are ignored.

I am attaching the output of dmesg, kernel & Xorg versions and my Xorg.0.log (created using startx -- -logverbose 10).

Please let me know if you need further info!
Thanks, Seb.

Comment 6 Seb 2010-01-23 20:41:30 UTC
Sorry, I misspellt your name, Jerome!

Comment 7 Matěj Cepl 2010-01-27 14:12:36 UTC
Dave, could we get the information requested in the comment 1 as well, please?

Thank you

Comment 8 Davide Repetto 2010-03-01 16:38:52 UTC
I'm really sorry Matej, but as said in the ticket, the customer took away the hardware.
I'll let you know if I manage to get my hands on it, but... No promises here. :(

Comment 9 Matěj Cepl 2010-03-10 22:59:52 UTC
OK, pushing this to Jerome, if he thinks he can make anything out of what we have.

Comment 10 Adam Pribyl 2010-03-11 15:02:55 UTC
F13 alpha here, ati radeon 9200, 19" Sony trinitron 400PS monitor - whatever I specify in xorg.conf is silently ignored, in favour of EDID, setting resolution to 1024x768 - while this monitor has no EDID available. There is no way to set higher resolution, even with Xrandr.

xorg.conf
Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        Monitor    "MonitorSony"
        DefaultDepth     24

        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes    "1400x1050" "1280x960" "1152x864" "1024x768" "800x600"
        EndSubSection
EndSection

[ 28565.624] (II) RADEON(0): Output VGA-0 using monitor section MonitorSony
[ 28565.649] (II) RADEON(0): Output DVI-0 has no monitor section
[ 28565.655] (II) RADEON(0): Output S-video has no monitor section
[ 28565.716] (II) RADEON(0): EDID for output VGA-0
[ 28565.717] (II) RADEON(0): Printing probed modes for output VGA-0
[ 28565.717] (II) RADEON(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsyn
[ 28565.717] (II) RADEON(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +v
[ 28565.717] (II) RADEON(0): Modeline "800x600"x56.2   36.00  800 824 896 1024  600 601 603 625 +hsync +v
[ 28565.718] (II) RADEON(0): Modeline "848x480"x60.0   33.75  848 864 976 1088  480 486 494 517 +hsync +v
[ 28565.718] (II) RADEON(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 489 492 525 -hsync -vs
[ 28565.742] (II) RADEON(0): EDID for output DVI-0
[ 28565.749] (II) RADEON(0): EDID for output S-video
[ 28565.749] (II) RADEON(0): Output VGA-0 connected
[ 28565.749] (II) RADEON(0): Output DVI-0 disconnected
[ 28565.749] (II) RADEON(0): Output S-video disconnected
[ 28565.749] (II) RADEON(0): Using fuzzy aspect match for initial modes
[ 28565.749] (II) RADEON(0): Output VGA-0 using initial mode 1024x768 +0+0
[ 28565.750] (II) RADEON(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[ 28565.750] (II) RADEON(0): mem size init: gart size :7dff000 vram size: s:8000000 visible:7cc0000
[ 28565.750] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM
[ 28565.750] (==) RADEON(0): DPI set to (96, 96)

Comment 11 Adam Pribyl 2010-05-06 18:55:07 UTC
I found that even the IgnoreEDID option for radeon driver is ignored... funny.

Changing the release to F13 and component to drv-ati.

Comment 12 Adam Pribyl 2010-05-18 16:05:44 UTC
Found after adding nomodeset to kernel, setting resolutions work OK, however the colors with depth 16 are very strange as everything except mouse cursor is so dark, it is almost invisible. Setting depth to 24 results in colors being OK...

Comment 13 Matěj Cepl 2010-11-09 14:09:32 UTC
*** Bug 571050 has been marked as a duplicate of this bug. ***

Comment 14 Adam Williamson 2011-03-29 18:10:30 UTC
Apparently this is still valid in F15. I'm not sure your modifications to xorg.conf are correct for RandR 1.2, though - can you take a look at http://wiki.debian.org/XStrikeForce/HowToRandR12 and check if they match that, and if not, try the format laid out there and see if you can force a mode that way? Thanks.

Comment 15 Adam Pribyl 2011-03-29 19:06:13 UTC
My xorg.conf may remain empty. How far I understand from the given URL, this is a feature. The mode should not be set anymore with Modeline in xorg.conf but with the sequence of commands like

gtf 1400 1050 75
xrandr --newmode <line generated by gtf>
xrandr --addmode VGA-0 <mode name by gtf>
xrandr --output VGA-0 --mode <mode name by gtf>

I am able to get a different resolution by those steps. The change is not permanent.

I have to use PrefferedMode in xorg.conf:

Section "Monitor"
	Identifier    "VGA-0"
	ModeLine "1400x1050_75.00"  155.85  1400 1496 1648 1896  1050 1051 1054 1096  -HSync +Vsync
	Option "PreferredMode" "1400x1050_75.00"
EndSection

So.. this is just me lacking behind then...?

Comment 16 Adam Williamson 2011-03-29 19:21:50 UTC
"My xorg.conf may remain empty. How far I understand from the given URL, this is
a feature. The mode should not be set anymore with Modeline in xorg.conf but
with the sequence of commands like"

sorta - the idea is that _in most cases_ it should be possible to run without xorg.conf and everything should Just Work, so that's how we set things up by default. But if you do need to override the auto-detection for some reason, such as a corner case like this one, xorg.conf is still the way to do it, but the syntax changed somewhat with the arrival of RandR 1.2.

if you can successfully use the mode you want to use via that stanza in xorg.conf, then yeah, everything is more or less as it should be; ideally we'd want to fix it up so you don't need to edit xorg.conf and it works alright with auto-detection, but in some cases that just isn't possible, and this might be one of those. If your monitor just doesn't provide an EDID, there isn't much we can do in the driver. So if the appropriate xrandr commands and xorg.conf stanza do what they should, I think we may just have to close this one.

If you're still seeing issues in GNOME Shell even running with KMS and this X configuration, please update the other bug to indicate that, and we can carry on looking at that one. thanks!

Comment 17 Adam Pribyl 2011-03-30 18:43:25 UTC
The monitor does not provided EDID. Using "PreferredMode" allows me to use desired resolution. I am closing this. If anybody still has a problem that ModeLine is ignored even with setup from comment 15, then please reopen. For me it works now OK. Thanks a lot for your attention.


Note You need to log in before you can comment on or make changes to this bug.