Bug 26897

Summary: RS690, Setting 1680x1050 mode causes monitor to reject timings
Product: xorg Reporter: Davin McCall <davmac>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
xorg.conf file
none
X server log (xf86-video-ati)
none
X server log (xf86-video-radeonhd)
none
clear pll flags none

Description Davin McCall 2010-03-04 17:05:15 UTC
Created attachment 33774 [details]
xorg.conf file

I have an X1250 / RS690 on a Gigabyte motherboard. With the xf86-video-ati driver, I get a blank screen on startup with the monitor displaying a box saying that an unsupported mode has been selected. The the radeonhd driver on the other hand it works fine.

With xrandr I can select lower resolution modes and they work fine with either driver.
Comment 1 Davin McCall 2010-03-04 17:06:09 UTC
Created attachment 33775 [details]
X server log (xf86-video-ati)
Comment 2 Davin McCall 2010-03-04 17:06:51 UTC
Created attachment 33776 [details]
X server log (xf86-video-radeonhd)
Comment 3 Davin McCall 2010-03-04 17:17:22 UTC
Forgot to mention: this happens with xf86-vide-ati 6.12.191, and also with earlier versions (eg 6.12.2).
Comment 4 Davin McCall 2010-03-04 17:41:38 UTC
Also, the monitor's "unsupported mode" message disappears and re-appears at short intervals (on for ~1 second, then disappears for a few seconds). When it disappears the screen remains completely blank (until the message re-appears).

My understanding is that the message should in fact be displayed semi-permanently if a bad mode is selected. I'm not sure why that's not happening in this case; it may not be relevant, but thought I'd mention it just in case.
Comment 5 Alex Deucher 2010-03-04 21:40:04 UTC
Does:
Option "NewPLL" "FALSE"
help?

Can you also try reverting 0c3468d812e3790ce03d9e76779ae81e7b7b82d5
Comment 6 Davin McCall 2010-03-05 00:44:03 UTC
Setting "NewPLL" "FALSE" doesn't help unfortunately.

Do you really need me to revert that change given that I have the exact same problem with 6.12.2? (which is yonks old). I will do it if you think it's important, but I don't normally run a git tree so it is more work than I'd rather do if it's not necessary. Please let me know.
Comment 7 Alex Deucher 2010-03-05 07:45:30 UTC
(In reply to comment #6)
> Setting "NewPLL" "FALSE" doesn't help unfortunately.
> 
> Do you really need me to revert that change given that I have the exact same
> problem with 6.12.2? (which is yonks old). I will do it if you think it's
> important, but I don't normally run a git tree so it is more work than I'd
> rather do if it's not necessary. Please let me know.
> 

yes, it changes different code.  However, I just noticed that just reverting it won't work in your case.  I'll provide a patch to test.
Comment 8 Alex Deucher 2010-03-05 07:48:07 UTC
Created attachment 33789 [details] [review]
clear pll flags

Can you try this patch?
Comment 9 Davin McCall 2010-03-05 16:07:02 UTC
Yes! That patch does the trick. Thanks!
Comment 10 Alex Deucher 2010-03-05 16:27:36 UTC
fix committed:
e7b41f8cb082ed462d29bf3fc440072424cbd852

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.