The radeon driver shipped with Fedora Core 5 exhibits very very
annoying default behavior, coming up in 640x480 mode because
(apparently) it is protecting the non-existant CRT2 from an out
of range signal.
It would sure be a better default if it assumed it should just
not run CRT2 at all when it can't identify it than to assume it
must run both displays at 640x480 :-).
Much poking around on the web eventually led me to discover that
(surprise!) there really is a "radeon" man page, and much poking
around in it led me to discover the "MonitorLayout" option where
I could tell it CRT2 was "NONE", so it finally works great (and
looks terrific on the hidef monitor), but it was an awful long
struggle to manually do something I really shouldn't have had to
System details since this may be a hardware specific problem:
I have an Sapphire branded ATI X700 Pro PCIE Radeon.
I have a single LCD monitor hooked to it on the DVI output, and
nothing at all plugged into any other output on the back of the
The monitor is Westinghouse LVM-42w2 HD flat panel intended to
run at 1920x1080 resolution. (Which is a whole other story since
the driver logs all the parameters needed to make the right
ModeLine when it gets the information from the monitor, but then
forces me to manually cut & paste then from the log file into a
ModeLine - why it doesn't provide that ModeLine automatically is
beyond my feeble brain's power to concieve :-).
I have a dual processor amd64 X2 system with 1 gig of memory in
an asus A8N-E motherboard.
I'll be attaching the xorg.tah.bug.tar.bz2 file which contains:
xorg.conf.working The working xorg.conf file.
Xorg.log.working The log from starting up with the
Xorg.log.busted The log from starting up when the
MonitorLayout option is commented out in
the xorg.conf file.
xorg.rpms The list of all the Fedora rpms
installed with xorg in their name.
Created attachment 5924 [details]
bzip2ed tar file of logs and such
Changing the summary line to something meaningful...
I'm not so sure the original title wasn't more meaningful :-).
Suppose I really did have CRT2 plugged in, but it was an old CRT
that won't report any useful info, wouldn't the same 640x480
nonsense still happen? Assuming NONE for CRT2 would still be
a better option because at least one screen would be working
at high enough resolutuon to be able to edit the xorg.conf
file by hand. Or assuming dual display rather than clone
and running just CRT2 at 640x480. There are loads of better
choices than the default it seems to pick right now.
(In reply to comment #3)
> I'm not so sure the original title wasn't more meaningful :-).
> Suppose I really did have CRT2 plugged in, but it was an old CRT
> that won't report any useful info, wouldn't the same 640x480
> nonsense still happen? Assuming NONE for CRT2 would still be
> a better option because at least one screen would be working
> at high enough resolutuon to be able to edit the xorg.conf
> file by hand. Or assuming dual display rather than clone
> and running just CRT2 at 640x480. There are loads of better
> choices than the default it seems to pick right now.
Having different modes on each crtc in clone mode IS the default behavior. I'm
not sure why it's not working properly for you, I've never seen this problem
before, and I'm not able to reproduce it. Are you still able to reproduce the
problem? Can you attach your xorg.conf from the "busted" set up?
The only difference between the busted and working xorg.conf file
is the busted one has a # at the beginning of the MonitorLayout line
to comment out that line, so just visualize the # and you'll
already have it :-).
Reproducing it is no problem. Comment out the MonitorLayout and
it happens every time.
(In reply to comment #3)
> I'm not so sure the original title wasn't more meaningful :-).
It is from the perspective of having a developer look at a list of
bugs and decide to look at one of them and maybe be interested in it
or do something about it. Your original summary was fairly vague
and useless, which would increase the chance of the bug sitting in
bugzilla forever and not having anyone look at it.
Being the nice guy I am, I decided to try and make the summary contain
some actually useful content, which might be useful when people search
through bugs, or try to find duplicates, etc.
When posting bugs, one should always post a "summary" in the Summary line
which is as useful as possible from a _developer_ perspective, as that
ultimately will make it easier to search, relate to, or get an idea
what the bug is about, without reading the entire bug report.
Being a developer on the receiving end of X bug reports for 6 years, I
think I've got a fairly good idea what a developer wants to see in the
Summary line. Generally, that means something useful and meaningful.
Interestingly enough, Alex responded not long afterward....
(In reply to comment #4)
> Having different modes on each crtc in clone mode IS the default behavior. I'm
> not sure why it's not working properly for you, I've never seen this problem
> before, and I'm not able to reproduce it.
I've seen other reports of CRTC2 incorrectly imposing limits on CRTC1, something
definitely seems wrong. IIRC CRTC2 mode validation can shrink the virtual size
from CRTC1 or something.
Is this title fine with everybody? :)
More info that might shed some light (or not :-).
When I first noticed the problem, I saw the errors in the log talking
about MergedFB, so the first fix I tried was finding out how to disable
the MergedFB stuff, and when I tried it, that also allowed the primary
display to work properly, but it bothered me that it was apparently
still trying to do the work to run two displays when I only had one
connected, so I eventually found the MonitorLayout option and went
with that (since I could convince it there was only one monitor
Another data point: I have Open SUSE 10.1 (I think it is 10.1 - whatever
the latest Open SUSE release is anyway) and it also uses the radeon driver,
but it is running xorg 6.8 or 6.9 (something before the 7.0 reorganization).
In any case, with the exact same hardware, but booted off the SUSE partition,
the radeon driver on SUSE doesn't exhibit this behavior (I still have to
manually create the ModeLine for the 1920x1080 display, but I don't have to
tell it a MonitorLayout to get it out of 640x480 mode). I can get
the exact rpm versions from the SUSE install when I get home if they
are any use.
Naturally I also have no idea what patches either RedHat or SUSE applied
to the xorg source when building their distributions.
Can you try adding some additional modes to the screen section of your config
with the "busted" setup? something like:
"1920x1080" "800x600" "640x480"
rather than just "1920x1080"
Does that change anything?
Adding the extra modes doesn't change anything, but I do have important
information. It turns out the display is actually running at 1920x1080.
I had previously merely believed xdpyinfo, but this time I thought to
bring up the info screen on the monitor, and it claims to be getting
a 60HZ 1920x1080 signal, exactly like the signal it gets when xdpyinfo
is reporting 1920x1080.
So X is deciding to run at only 640x480 "logical" resolution, but is actually
scaling the bits up to fill a 1920x1080 screen.
This probably goes through some totally different path in the driver logic
having something to do with the extension (who's name I forget) that does
the different resolution switching.
However, Alt-plus and Alt-minus and the screen resolution picker in gnome
won't switch out of the 640x480 logical mode, so from the standpoint of
the user sitting out in front, it might as well be stuck in 640x480
(but the whole universe no doubt shifts from the standpoint of the bug
*** Bug 7203 has been marked as a duplicate of this bug. ***
In a new twist: I just tried to install Fedora Core 6 test 1 in a different
partition on this same machine, and whatever version of the radeon driver
(or maybe the installer uses the vesa driver?) is on the FC6t1 DVD has the
same problem during installation (where it is much harder to manually fix
the xorg.conf file :-). I wound up putting an old CRT on the VGA port and
disconnecting the DVI while doing the install.
anaconda (the Red Hat installer) uses the same video driver during installation
that will be used on the system at runtime after installation. The vesa
driver is not used, unless a given chip is totally unsupported, or is known
to be completely broken on a given piece of hardware.
All radeon hardware supported by the radeon driver, is configured to use
the radeon driver currently. The driver that ships with FC6test1 is
the one that shipped in X11R7.1, which I believe is 6.6.0, however 6.6.1
is in rawhide currently.
So whatever the problem happens to be, it's a current problem in X11R7.1
with all released tarball updates released by X.Org that have been released
If bug 7203 is really a dup of this one, maybe my experience will be useful.
This updates some comments I made there.
I have a Thinkpad T41 (Radeon Mobility M7 LW [Radeon Mobility 7500]) running
FC5. If I start X with an external monitor with no PnP, I see an incorrect
resolution internal and external:
SZ: Pixels Physical Refresh
*0 848 x 480 ( 287mm x 163mm ) *-25880
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none
If I start X with a PnP monitor attached, I get normal 1024x768 resolution
(internal and external).
If I start X with no external monitor attached, I get normal resolution, but
when I plug in an external monitor, there is no external display.
I added 'option "BIOSHotKeys" "on"' to the Device section of xorg.conf. This
changes the behavior as follows:
Starting with non-PnP monitor results in the above incorrect resolution
internally and externally.
Starting with no external monitor results in correct resolution but no external
signal. Hitting Fn-F7 now correctly cycles through LCD on/CRT off -> LCD
off/CRT on -> LCD on/CRT on -> LCD off/CRT off.
So for me, BIOSHotKeys is an effective workaround for the issue I'm seeing.
I would rate this problem with much higher priority than it has been given. I
have tried the work-arounds that others have suggested, and they have not
assisted. My machine is useless under Linux when it is restricted to 848x480
resolution. I have been forced to working under MS Windows instead, a painful
The problem is that the resolution of the primary head reverts to what the
radeon driver thinks that the secondary head wants, and will not be diverted
from its notion of what the secondary head is capable of despite numerous
attempts to specify it through xorg.conf. There is no problem if nothing is
plugged in to the secondary head.
Option "MonitorLayout" "LVDS, NONE"
but of course this puts nothing out to the secondary head.
Option "MonitorLayout" "LVDS, SVGA"
but this is no different from the default in its behaviour.
I also tried adding
Option "PanelSize" "1280x1024"
but then I get nothing on the local or secondary screen.
Option "BIOSHotKeys" "on"
also gave me a black screen.
I will attach some log files from the various attempts.
Created attachment 6438 [details]
The archive contains a log from when "none" was specified, when "SVGA" was specified, and when "PanelSize" was specified.
(In reply to comment #15)
> I would rate this problem with much higher priority than it has been given. I
> have tried the work-arounds that others have suggested, and they have not
> assisted. My machine is useless under Linux when it is restricted to 848x480
> resolution. I have been forced to working under MS Windows instead, a painful
> The problem is that the resolution of the primary head reverts to what the
> radeon driver thinks that the secondary head wants, and will not be diverted
> from its notion of what the secondary head is capable of despite numerous
> attempts to specify it through xorg.conf. There is no problem if nothing is
> plugged in to the secondary head.
> I tried
> Option "MonitorLayout" "LVDS, NONE"
> but of course this puts nothing out to the secondary head.
> I tried
> Option "MonitorLayout" "LVDS, SVGA"
> but this is no different from the default in its behaviour.
"SVGA" is not a valid option. Try CRT instead. I doubt these will fix the
problem however. Try:
Option "MergedFB" "false"
or try specifying CRT2Hsync and CRT2Vrefresh along with appropriate metamodes.
See the radeon man page for more.
>Option "MergedFB" "false"
This was one of the options that worked for me after playing around with
my original bug (which was due to it incorrectly deciding I did have a
second display even when I don't), so maybe it will work with a real
second display as well (I'm using the MonitorLayout option these days
to tell it I don't have a second display since that corresponds more
closely to the facts).
None of these workarounds can be applied during an install, however, because
you can't get control from anaconda to change the X config it builds, so
this does seem like a pretty serious problem for installs (of course, you
can always install text mode but that's horrible :-).
Thanks, Tom. The combination of
Option "MergedFB" "false"
Option "BIOSHotKeys" "on"
in the "Device" section without a MonitorLayout has got me working correctly.
I just installed the Fedora Core 6 prerelease (x86_64) and my original problem
seems to be gone now. It no longer forces me to use 640x480 or 800x60 with
the default xorg.conf file (no need to tell it CRT2 is NONE anymore). The
radeon driver is probably from this rpm: xorg-x11-drv-ati-6.6.2-2.fc6.
I actually got the native 1920x1080 display in the initial login screen
Here's my FC6 Thinkpad T41 experience:
Installation was no problem, first boot came up with normal 1024x768 resolution.
The T41 requires radeonfb to work around a suspend-to-RAM power consumption
issue, so I installed that in initrd. I have the default xorg.conf created at
install. Rebooting brings the primary display up in a low-res mode (640x480 or
800x600). Removing the radeonfb module reverts to normal behavior. (To this
point, I have not tested the external display.)
Installing radeonfb and adding options MergedFB off and BIOSHotKeys on makes the
primary display come up in normal 1024x768 mode.
At this point, I could not get the external display to work. Cycling Fn-F7
produced either no output or a black screen. I discovered that the external
display had been disabled in the BIOS (though I had made no changes there
myself). Re-enabling it caused everything to work as expected.
"my original problem seems to be gone now", "I discovered that the external
display had been disabled in the BIOS ... Re-enabling it caused everything to work as expected."
So this is fixed, then?
Back in comment #20 I said that my original problem seemed to be fixed
somewhere between whatever X shipped with fedora core 5 versus fedora core 6.
Not sure if all the folks who chimed in since then had all their
problems fixed though :-).