| Summary: | Limited resolution on primary head due to incorrectly imposing limits from secondary | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Tom Horsley <horsley1953> | ||||||
| Component: | Driver/Radeon | Assignee: | Xorg Project Team <xorg-team> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | high | CC: | alexdeucher, g-freeman, jslupski, mjs | ||||||
| Version: | 7.0 (2005.12) | ||||||||
| Hardware: | x86 (IA32) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
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. :o) 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 that way). 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 finder :-). *** 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 since then. HTH 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: $ xrandr 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 experience. 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. I also tried adding Option "PanelSize" "1280x1024" but then I get nothing on the local or secondary screen. The option 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 > experience. > > 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. >Try:
>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 after installation. 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 :-). |
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.
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 do. 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 video card. 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 working file. 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.