Bug 142268
Summary: | External Monitor shows 640x480 panning window, not actual desktop size | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | redhat-bugs <dave> | ||||||||||
Component: | xorg-x11 | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> | ||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 2 | ||||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | i386 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2004-12-22 13:45:18 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
redhat-bugs
2004-12-08 17:35:12 UTC
Created attachment 108127 [details]
What happens when the Acer is connected
Created attachment 108128 [details]
What happens when the Sony is connected
Created attachment 108130 [details]
What happens when nothing is connected
Created attachment 108131 [details]
My xorg.conf
Opened this as a bug with xorg; see https://bugs.freedesktop.org/show_bug.cgi?id=2035 Their response: NOTABUG Details: ------- Additional Comments From agd5f 2004-12-08 14:25 ------- the radeon driver defaults to driving each display with a separate crtc (called clone mdoe). if it can't find the DDC data for the attached monitor it defaults to 640x480@60Hz to avoid potentially damaging you monitor. You can either disable clone mode (in which case crtc1 will drive both outputs) or add the use the clonehsync and clonevrefresh options (to tell the driver the monitor's limits when it can't get DDC data). see that radeon man page for more about the options. ------- Additional Comments From agd5f 2004-12-08 14:30 ------- for your coworker, in 6.8.x the options have changed a bit, see the radeon man page for more. ...so clearly the problem is that there's no way to set the required Radeon options through the display control panel. Would this be an enhancement request? (I doubt it -- the current fashion is to remove options from GUI applications, not add more.) Upstream is right, this is not a bug. If your monitor or LCD panel can not be DDC probed, or otherwise autodetected, then the driver must make assumptions as to how to drive the hardware in a safe manner without damaging the panel or monitor. That basically means choosing low resolution/refresh which is unlikely to damage the display. Some hardware is not autodetectable at all. I don't know wether this is the case for your hardware or not. Windows generally wont ever show this type of problem because either WIndows autodetects the hardware, or if not detectable, Windows has .INF files that specify the hardware's capabilities, which are supplied directly by the manufacturers. There are also other possibilities that are more complex than I will get into in a bug report. The bottom line basically though, is that if DDC is unavailable, for whatever reason, you must manually configure the display in your X server config file, or the drivers will use defaults chosen to be as safe as possible. My recommendation is to upgrade to Fedora Core 3 (our currently supported release), and update the OS to all latest rpms via yum or up2date. After doing so, run: system-config-display --reconfig Then reboot completely to do full hardware reset. In the new startup, run X and see if things are better at all. If not, then experiment with the various Radeon driver specific options on the "radeon" manpage, and with configuring the display panel via xorg.conf. If you require assistance at all, use the X.Org xorg mailing list to seek help. You may also want to repeat this with the xorg-x11 from rawhide, which is a newer release with several Radeon driver fixes and enhancements. This may or may not help your problem depending on wether it is a real driver issue, or just lack of DDC capability in your system. After doing all of this, if you still believe there may be a real bug at heart, feel free to file a new bug in freedesktop.org bugzilla for review, indicating the current OS release, xorg release, etc. that you are using. Generally speaking, if X.Org does not consider something an X.Org bug, Red Hat X developers and other community X developers are likely to arrive at similar conclusions. Setting status to "CURRENTRELEASE" Yeah, I get that. It isn't an Xorg bug. In the FC3 case, the answer is to add lines: Option "CRT2HSync" "30.0 - 82.0" Option "CRT2VRefresh" "50.0 - 90.0" ..to the "Device" section describing my radeon device. These values were divined by manually adding the monitor through the Display control panel, and then transfering those values into the Option fields. (As the response from xorg says, consult your "radeon" man page for the equivilent commands in FC2.) The problem is that setting the monitor type in the system-config-display should cause the system to use that monitor type, and it doesn't (because the Radeon is treating the external monitor plug as a separate display, which may be fine, but there's no way to change that from system-config-display, which isn't). This, incidentally, is still true in FC3 with all the current updates applied. So. Should I refile this as a FC3 bug in system-config-display? |