From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20050922 Firefox/1.4 Description of problem: Yum upgraded xorg-x11 for me, and afterward, I could not set the resolution on my Dell 2000fp monitor to 1600x1200, it's natural resolution. When I set the resolution to 1600x1200, the on-screen display of the monitor still showed 1280x1024 @ 75Hz. Reverting to xorg-x11-6.8.1-12 fixed the problem. This is a large problem, as the monitor looks horrible when it is not run at 1600x1200. Version-Release number of selected component (if applicable): xorg-x11-6.8.2-1.FC3.45.1 How reproducible: Always Steps to Reproduce: 1. 2. 3. Additional info:
Run "rpm -qa |grep xorg-x11" and post the results here. Also please attach as a bugzilla file attachment, a copy of your X server config file, and a log file from the working X server (old version) and the non-working X server (the update). We can then analyze the differences for clues. Thanks in advance. Setting status to "NEEDINFO_REPORTER"
I just tried the new xorg version out toda and still had the problem. Here is the result of "rpm -qa | grep xorg-x11" when I ran the latest version: xorg-x11-Xdmx-6.8.2-1.FC3.45.2 xorg-x11-libs-6.8.2-1.FC3.45.2 xorg-x11-deprecated-libs-6.8.2-1.FC3.45.2 xorg-x11-doc-6.8.2-1.FC3.45.2 xorg-x11-Mesa-libGL-6.8.2-1.FC3.45.2 xorg-x11-devel-6.8.2-1.FC3.45.2 xorg-x11-xdm-6.8.2-1.FC3.45.2 xorg-x11-tools-6.8.2-1.FC3.45.2 xorg-x11-Mesa-libGLU-6.8.2-1.FC3.45.1 xorg-x11-deprecated-libs-devel-6.8.2-1.FC3.45.2 xorg-x11-font-utils-6.8.2-1.FC3.45.2 xorg-x11-xfs-6.8.2-1.FC3.45.2 xorg-x11-twm-6.8.2-1.FC3.45.2 xorg-x11-Xvfb-6.8.2-1.FC3.45.2 xorg-x11-6.8.2-1.FC3.45.2 xorg-x11-sdk-6.8.2-1.FC3.45.2 xorg-x11-xauth-6.8.2-1.FC3.45.2 xorg-x11-Xnest-6.8.2-1.FC3.45.2 Here is the result now, after I downgraded (using the instructions at https://www.redhat.com/archives/fedora-list/2005-September/msg02688.html; looks like some the new packages stick around): xorg-x11-Xdmx-6.8.2-1.FC3.45.2 xorg-x11-font-utils-6.8.1-12 xorg-x11-tools-6.8.1-12 xorg-x11-libs-6.8.2-1.FC3.45.2 xorg-x11-deprecated-libs-6.8.2-1.FC3.45.2 xorg-x11-doc-6.8.1-12 xorg-x11-xauth-6.8.1-12 xorg-x11-Xvfb-6.8.1-12 xorg-x11-libs-6.8.1-12 xorg-x11-Mesa-libGLU-6.8.1-12 xorg-x11-6.8.1-12 xorg-x11-xdm-6.8.1-12 xorg-x11-doc-6.8.2-1.FC3.45.2 xorg-x11-Mesa-libGL-6.8.2-1.FC3.45.2 xorg-x11-devel-6.8.2-1.FC3.45.2 xorg-x11-xdm-6.8.2-1.FC3.45.2 xorg-x11-tools-6.8.2-1.FC3.45.2 xorg-x11-Mesa-libGLU-6.8.2-1.FC3.45.1 xorg-x11-Mesa-libGL-6.8.1-12 xorg-x11-deprecated-libs-6.8.1-12 xorg-x11-deprecated-libs-devel-6.8.1-12 xorg-x11-Xdmx-6.8.1-12 xorg-x11-deprecated-libs-devel-6.8.2-1.FC3.45.2 xorg-x11-font-utils-6.8.2-1.FC3.45.2 xorg-x11-xfs-6.8.2-1.FC3.45.2 xorg-x11-twm-6.8.2-1.FC3.45.2 xorg-x11-Xvfb-6.8.2-1.FC3.45.2 xorg-x11-6.8.2-1.FC3.45.2 xorg-x11-sdk-6.8.1-12 xorg-x11-devel-6.8.1-12 xorg-x11-Xnest-6.8.1-12 xorg-x11-sdk-6.8.2-1.FC3.45.2 xorg-x11-xauth-6.8.2-1.FC3.45.2 xorg-x11-Xnest-6.8.2-1.FC3.45.2 xorg-x11-xfs-6.8.1-12 xorg-x11-twm-6.8.1-12 The attachment with the config and log files is coming; let me know if you need anything else.
Created attachment 119204 [details] xorg.conf file and log files from old and new X servers
Review the instructions in bug #168844 to resolve the duplicate package problem. Comment #13 IIRC. Please reattach the log/config files as individual uncompressed file attachments so they are web browser viewable. Please edit your xorg.conf, and add the following option to the "ServerFlags" section. If there is no ServerFlags section, create a new one as such: Section "ServerFlags" Option "PciOsConfig" "1" EndSection Then save and exit, and reboot the system, then start the X server up again. Indicate wether the video problem is resolved or not. If the problem is still present, remove the above option, and replace it with the following option instead, and try again: Option "PCIProbe1" "1" Does this option resolve the issue? If not, please try the following: Option "PCIProbe2" "1" If any of these 3 options work around the problem, please update the bug report to let us know which ones. Be sure to reboot the machine before each try, to ensure a full hardware reset. This will help us to narrow down wether the problem is related to the PCI configuration changes, or elsewhere. Thanks in advance for testing. Setting status to "NEEDINFO_REPORTER" and awaiting feedback. Thanks in advance.
Created attachment 119208 [details] config file
Created attachment 119209 [details] X log file from working version 6.8.1-12
Created attachment 119210 [details] X log file from broken version 6.8.2-1.FC3.45.2
I tried all 3 of those changes to the xorg.conf file, rebooting between each change, and none of them solved the problem. Let me know if I can do anything else to help.
xorg-x11-6.8.2-37.FC4.49.3.test_no_i945.0 is now available for download via ftp at the following URL: ftp://people.redhat.com/mharris/testing/fc4 Please upgrade to these rpms, and remove any of the options you may have added from comment #4 above from your config file. Reboot the system completely after the update, and start X again after the system comes up. Does this problem go away? Please attach the X server log from after testing this beta release.
The problem is fixed with these new test rpms. I will attach the X server log. Thanks so much!
Created attachment 119240 [details] X server log for version 6.8.2-37.FC4.49.3.test_no_i945.0
Thanks, that confirms the i945 patch seems to have regressed i865 support.
I had a chat with alanh in IRC about this issue this morning, and it turns out that the i810 driver enforces DDC to be used now, and drops modes on the floor which exceed the monitor's DDC supplied ratings. The Dell 2000FP is a little funky in that it only supports 160MHz as it's maximum pixel clock yet it's own 1600x1200 mode uses 162MHz, so the Xserver drops the mode on the floor. </paraphrase> Suggested workaround, is to force DDC to be disabled, by adding the following to the Device section of the config file: Option "NoDDC" Does this make the problem go away, or affect it at all? Setting status to "NEEDINFO_REPORTER", and awaiting testing results.
To clarify, I assume you want me to switch back to the latest official release to try this option? Also, what's the proper way with rpm to switch back to that release from the test release? Thanks!
(In reply to comment #14) > To clarify, I assume you want me to switch back to the latest official release > to try this option? Also, what's the proper way with rpm to switch back to that > release from the test release? Thanks! Correct. I updated 3 or 4 bugs in the same timeframe with the same suggestion, and included instructions on how to downgrade in them, but I seem to have left that out of this one by mistake. ;o) I don't know if you can downgrade using 'yum' or not. The docs don't seem to indicate any method. You can download the xorg-x11 main binary rpm though, and do: rpm -Uvh --oldpackage <package> That should work. Hope this helps.
I can confirm that this problem is fixed in the current release 6.8.2-1.FC3.45.2 with the NoDDC option enabled. I'll attach the X server log. So I guess this bug is actually with the 2000fp?
Created attachment 119321 [details] X server log for 6.8.2-1.FC3.45.2 with NoDDC option enabled
(In reply to comment #16) > I can confirm that this problem is fixed in the current release 6.8.2-1.FC3.45.2 > with the NoDDC option enabled. I'll attach the X server log. So I guess this > bug is actually with the 2000fp? According to Alan, this is the case, and the log files would seem to back that up if I'm reading things correctly: Here's some of the log messages from the non-working 6.8.2-1.FC3.45.2 log you provided in comment #7: (II) I810(0): Using detected DDC timings (II) I810(0): HorizSync 31-80 (II) I810(0): VertRefresh 56-76 I'll attach the full diff in a minute... ... (1600x1200,Monitor0) mode clock 162MHz exceeds DDC maximum 160MHz And the log from comment #17: (**) I810(0): Option "NoDDC" ... (II) I810(0): Monitor0: Using hsync range of 31.00-80.00 kHz (II) I810(0): Monitor0: Using vrefresh range of 56.00-76.00 Hz (II) I810(0): Not using mode "1400x1050" (no mode of this name) (II) I810(0): Not using mode "1280x960" (no mode of this name) (II) I810(0): Not using mode "1152x864" (no mode of this name) (II) I810(0): Increasing the scanline pitch to allow tiling mode (1600 -> 2048). (--) I810(0): Virtual size is 1600x1200 (pitch 2048) (**) I810(0): *Built-in mode "1600x1200" (**) I810(0): *Built-in mode "1280x1024" (**) I810(0): *Built-in mode "1024x768" (**) I810(0): *Built-in mode "800x600" (**) I810(0): *Built-in mode "640x480" (II) I810(0): Attempting to use 60.00Hz refresh for mode "1600x1200" (85a) (II) I810(0): Attempting to use 75.02Hz refresh for mode "1280x1024" (858) (II) I810(0): Attempting to use 75.08Hz refresh for mode "1024x768" (854) (II) I810(0): Attempting to use 75.00Hz refresh for mode "800x600" (852) (II) I810(0): Attempting to use 75.00Hz refresh for mode "640x480" (850) (**) I810(0): Display dimensions: (410, 310) mm (**) I810(0): DPI set to (99, 98)
Created attachment 119330 [details] diff between the two logs
Here's another highlight: -(WW) I810(0): Correcting plane A stride (1280 -> 2048) -(II) I810(0): Mode bandwidth is 78 Mpixel/s -(II) I810(0): maxBandwidth is 640 Mbyte/s, pipe bandwidths are 420 Mbyte/s, 0 Mbyte/s +(WW) I810(0): Correcting plane A stride (1600 -> 2048) +(II) I810(0): Mode bandwidth is 115 Mpixel/s +(II) I810(0): maxBandwidth is 640 Mbyte/s, pipe bandwidths are 632 Mbyte/s, 0 Mbyte/s So, the EDID data provided by the hardware seems to be broken on this hardware.
Bummer. Well, this workaround seems to do the trick for me. I hope you guys can find a better solution. Let me know if you need more testing help. Thanks!
Similar situation. After an xorg-x11 upgrade I lost the ability to set my display resolution to 1600x1200. Dell Dimension 3000, Intel 865 builtin controller, Dell 2001FP monitor. Kernel 2.6.13-1.1526_FC4. xorg-x11-6.8.2-31 is OK. xorg-x11-6.2.8-37.FC4.4.49.2 not OK. The Option "NoDDC" workaround fixes xorg-x11-6.2.8-37.FC4.4.49.2.
This is a bug in the actual display. Some of Dell's displays provide bad EDID data to the X server, so when DDC is enabled, the X server gets incorrect results from the display and uses them, assuming they are correct - which they really should be (or what's the point of plug and play). The upstream Intel i810 driver maintainer has made the Intel driver default to using DDC in the latest driver releases, which unmasks this flaw in Dell's flat panels. The only way to avoid the issue on the broken displays, is to manually disable DDC probing in the config file. Since this is not a bug in the driver, but a bug in the hardware, this workaround is required. It is theoretically possible to have the video driver (or X server) include a blacklist of known broken hardware, and either munge the bad EDID data via software, or alternatively just auto-disable DDC on known broken hardware, however this is a rather ugly solution which would likely be considered hacky by other developers, and might be rejected by upstream. Either way, any long term solution will have to be implemented in the upstream sources, rather than distribution specific hacks, so please file a bug report in X.Org bugzilla for this problem if you would like to see a hardware blacklist or some other solution implemented in future X.Org releases. For the time being however, users with the broken Dell displays will need to manually override DDC in their config files. Setting status to "WONTFIX", as this is a hardware flaw, which needs to be worked around upstream, before we'll consider changing anything locally.