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):
Steps to Reproduce:
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
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:
Here is the result now, after I downgraded (using the instructions at
like some the new packages stick around):
The attachment with the config and log files is coming; let me know if you need
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:
Option "PciOsConfig" "1"
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]
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.
Suggested workaround, is to force DDC to be disabled, by adding the
following to the Device section of the config file:
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
+(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
So, the EDID data provided by the hardware seems to be broken on this
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.
xorg-x11-6.8.2-31 is OK. xorg-x11-6.2.8-37.FC184.108.40.206 not OK.
The Option "NoDDC" workaround fixes xorg-x11-6.2.8-37.FC220.127.116.11.
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.