Bug 5184

Summary: Warning: mode clock 31.5MHz exceeds DDC maximum 0MHz
Product: xorg Reporter: Jon Burgess <jburgess777>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: minor    
Priority: high CC: libv
Version: 7.1 (2006.05)   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Log file with 0MHz entries
none
Config file none

Description Jon Burgess 2005-11-28 10:42:32 UTC
It looks like Xorg probes the monitor via DDC OK, but I get lots of warnings
like the summary in the log file:
...
(WW) (640x350,Monitor0) mode clock 31.5MHz exceeds DDC maximum 0MHz
(WW) (320x175,Monitor0) mode clock 15.75MHz exceeds DDC maximum 0MHz
(WW) (640x400,Monitor0) mode clock 31.5MHz exceeds DDC maximum 0MHz
(WW) (320x200,Monitor0) mode clock 15.75MHz exceeds DDC maximum 0MHz
(WW) (720x400,Monitor0) mode clock 35.5MHz exceeds DDC maximum 0MHz
(WW) (360x200,Monitor0) mode clock 17.75MHz exceeds DDC maximum 0MHz
...

The code seems to fall back to some default modes and works OK, but 0Mhz doesn't
appear to be a sensible maximum clock.
Comment 1 Jon Burgess 2005-11-28 10:45:10 UTC
Created attachment 3923 [details]
Log file with 0MHz entries
Comment 2 Jon Burgess 2005-11-28 10:46:01 UTC
Created attachment 3924 [details]
Config file
Comment 3 Jon Burgess 2005-11-29 09:51:31 UTC
It looks like this warning has started appearing because the interpret_edid.c
code is now setting max_clock=0 when the monitor doesn't specify a value. The
old code used to set 2550MHz in this case. This trips up the code in xf86Mode.c
which still looks for the 2550MHz value. 

I've looked into the source and it is clear that this isn't a mach64 driver
problem, but i'm not sure which component it should be recorded against.

See
http://cvsweb.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/ddc/interpret_edid.c?r1=1.2&r2=1.3

and programs/Xserver/hw/xfree86/common/xf86Mode.c:

768 : 	  	  	 if (mon_range->max_clock < 2550 &&
769 : 	  	  	mode->Clock / 1000.0 > mon_range->max_clock) {
770 : 	  	  	xf86Msg(X_WARNING,
771 : 	  	  	"(%s,%s) mode clock %gMHz exceeds DDC maximum %dMHz\n",
772 : 	  	  	mode->name, monitor->id,
773 : 	  	  	mode->Clock/1000.0, mon_range->max_clock);
774 : 	  	  	}

Comment 4 Adam Jackson 2006-04-05 00:14:10 UTC
i think the change in 1.3 needs to be rolled back.
Comment 5 Adam Jackson 2006-05-16 23:45:27 UTC
(In reply to comment #4)
> i think the change in 1.3 needs to be rolled back.

but i'm not going to do it right now; out to 7.2.
Comment 6 Sami Farin 2006-05-17 01:15:29 UTC
I have MGA and IA-32.
I tried reverting change in v1.3 and results were:
I got no "...exceeds DDC maximum 0MHz" warnings but
refresh rate was still 55 Hz (instead of 91Hz I have had since 1999).

I also nuked DDC out of the game, but 55 Hz was the max.
And why does Xorg ignore my VertRefresh and/or HorizSync settings?
Where does it pull the magic numbers 55 Hz and 60 kHz
and how can I make latest Xorg work?
Now I have to use v1.0.1.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188770
Comment 7 Daniel Stone 2006-11-04 09:45:30 UTC
ajax: still worth doing for 7.2?
Comment 8 Adam Jackson 2006-12-10 15:45:09 UTC
This is solved in a better way by the autoconfig branch merge, and should no
longer happen in server 1.2.  Removing from the tracker.

Still a sensible thing to do for 1.1 though.  For anyone reading this: the chunk
from interpret_edid.c is correct, xf86Mode.c needs to be updated to not
interpret a max_clock of 0 as really meaning no signals allowed.
Comment 9 Daniel Stone 2007-02-27 01:28:57 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 10 Adam Jackson 2010-08-09 12:46:20 UTC
No one's doing xserver 1.1 updates, ever.

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.