When my Dell Lattitude C640 laptop is docked, XFree86 would insist on using the 640x480 resolution and nothing bigger (despite both ddcprobe and XF86Config correctly identifying the monitor). When not docked, the exact same config works fine (X would use 1400x1050). I have not tried attaching the external monitor (instead of docking), but my 8.0 experience suggests that with external monitor it would work exactly the same way as when docked. In 8.0 the radeon driver would insist on limiting the resolution at 1280x1024 when docked or when external monitor is plugged in, but with the Option "CrtScreen" it was happy to run at 1600x1400. But since XFree86 in Phoebe has a new radeon driver, that option no longer works. Of course, the problem is only made worse by the fact that neither of the two versions of the radeon driver seems to have any documentation. I considered it OK to have to read the source code to figure out the possible options and find a way to go from 1280x1024 to 1600x1400, but IMHO 640x480 is so bad (note that this means that even anaconda graphics mode runs with virtual resolution > display resolution) that things need to work better by default. ddcprobe when docked: Videocard DDC probe results Description: ATI Technologies Inc. P7 Memory (MB): 32 Monitor DDC probe results ID: DEL5000 Name: Dell P1130 Horizontal Sync (kHZ): 30-130 Vertical Sync (HZ) : 48-170 Width (mm): 400 Height(mm): 300 ddcprobe when not docked: Videocard DDC probe results Description: ATI Technologies Inc. P7 Memory (MB): 32 Monitor DDC probe results Monitor DDC Probe failed. I'll attach the config file and the log files (for docked and undocked).
Created attachment 89137 [details] XF86Config (created by redhat-config-xfree86 when docked)
Created attachment 89138 [details] XFree86.0.log (when running docked) A few highlights from the log: These lines are logged in both cases: (II) RADEON(0): CloneDisplay option not set -- defaulting to auto-detect (II) RADEON(0): Primary Display == Type 2 (II) RADEON(0): Panel ID string: SHARP LQ14F1LH02 (II) RADEON(0): Panel Size from BIOS: 1400x1050 Does this mean that "auto-detect" is not quite working? Or that it does not realize what "primary display" should be used when docked? The following lines are present only when docked: (II) RADEON(0): Clone modes validation ------------ (II) RADEON(0): DDC detection (type 3) for clone modes (WW) RADEON(0): Monitor0: Using default hsync range of 28.00-33.00kHz (WW) RADEON(0): Monitor0: using default vrefresh range of 43.00-72.00Hz after that it quickly decides that all hi-res modes have too big hsync and ends up with 640x480 as the only available mode.
Created attachment 89139 [details] XFree86.0.log (when not docked) This log is produced using the exact same config as the previous one.
Status update: If I just add Option "CloneDisplay" "0" to the "Device" section, X gives up on trying to do anything special for the external monitor and just uses the snandard "1400x1050" resolution on both LCD and external CRT. This is much better than 640x480, but still not as good as 1600x1200 I used to have. I tried using Option "CloneMode" "1600x1200" Option "CloneHSync" "30.0 - 130.0" Option "CloneVRefresh" "48.0 - 170.0" and this had an effect of increasing the virtual size to 1600x1200, but I still get (WW) RADEON(0): Monitor0: Using default hsync range of 28.00-33.00kHz (WW) RADEON(0): Monitor0: using default vrefresh range of 43.00-72.00Hz
Ah, I found documentation for the driver - see http://www.morlug.org/radeon Also turned out that I almost got it last time - the only issue was that there can be no spaces in CloneHSync and CloneVRefresh, so Option "CloneMode" "1600x1200" Option "CloneHSync" "30.0-130.0" Option "CloneVRefresh" "48.0-170.0" worked perfectly. -------- Based on the above, the suggested solutions are: 1) (quick fix) Modify redhat-config-xfree86 (and anaconda) to add the appropriate CloneMode/CloneHSync/CloneVRefresh options to the "Device" section whenever the radeon driver is used (it should just use the same hsync and vrefresh value ranges as in "Monitor" section, just w/o spaces). The CloneMode should probably have the highest resolution (or can also be omitted). 2) Teach the radeon driver to do the DDC on the external monitor (after all, ddcprobe does list the correct hsync/vrefresh, so the information is accessible) to figure out the CloneHSync/CloneVRefresh automatically 3) It would probably be best to do both (1) and (2) CCing bfox for the redhat-config-xfree86 part. ------ P.S. Is redhat-config-xfree86 capable of doing two-headed setups? If so, it would be really great if it knew how to do it for the radeon cards that support it (now that the driver is capable of it).
No, redhat-config-xfree86 cannot currently do dual-head setups. There have been many requests so it's on my plans for the future, but not this release. (I had no idea so many people ran dual-head setups)
OK, then it's just down to choices 1-3 in comment #5. Does that sounds reasonable?
No, it does not sound reasonable. Any such changes like this must not break _existing_ working setups. This problem most likely is not going to change unless it is changed upstream. There are known workarounds as you've indicated above also.
*** Bug 81149 has been marked as a duplicate of this bug. ***
First, clarification - this is only about the resolution on external CRT. The LCD always works correctly (even when CRT is plugged in!). Sorry if I confused you - I was confused at first myself, since I did not realized that the new 4.3 driver (as opposed to the old 4.2 driver) now *by default* tries running LCD and CRT at *separate* resolutions (while showing the same image). Second, your comment #8 make very little sense to me. > Any such changes like this must not break _existing_ working setups. What do you mean by "existing setups"? The new XFree86 has a completely different (compared to Red Hat 8.0/ Xfree86 4.2) radeon driver. The mere fact of upgrading from previous versions of RedHat would break existing setups. This bug is about making sure that does not happen. > This problem most likely is not going to change unless it is changed upstream. What upstream? My suggested solution "1" is to extend redhat-config-xfree86 to better support the quirks of the new driver. Also, I never suggested that solution "2" should be implemented by Red Hat. I only asked which solution appears the most reasonable, and if consensus will be that "2" is a reasonable choice, then of course I will report it upstream, Basically, I am not completely sure whether this is a configuration issue or a driver issue - it seems to me that this is more of a configuration issue than a driver issue (and quite possibly a combination of the two), Right now I first want to get an expert *opinion* on how this should be best solved.
>Right now I first want to get an expert *opinion* on how this should be best >solved. By mailing a tech support forum such as xfree86. I don't know what the best solution to the problem is. I don't consider it a high priority (like the severity field suggests) to determine that however either. Bugzilla is not a tech support forum, and the more questions and discussions that occur in bugzilla, that could/should be occuring on public mailing lists (IMHO), then the more time I'm spending in bugzilla, and the less time I'm spending fixing real bugs that get reported - perhaps even this one. I have no laptop hardware in any case, so I'm totally unlikely to be running X in a debugger on a non-laptop to solve a problem that happens on one laptop (or any laptop), especially if there is a workaround. Query bugzilla for the total number of bugs open right now against XFree86, realizing there is one person on the other side of the fence. I hope you understand that all 200 bugs wont be fixed before the final OS release. Unless this one gets fixed upstream, it probably will remain as-is unless some patch turns up on a mailing list somewhere that fixes it or something. Sorry, but I don't have a lot of time to invest in a problem that could be very difficult to solve without hardware.
This seems to be working correctly in Cambridge alpha1