Bug 26897 - RS690, Setting 1680x1050 mode causes monitor to reject timings
Summary: RS690, Setting 1680x1050 mode causes monitor to reject timings
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-04 17:05 UTC by Davin McCall
Modified: 2010-03-05 16:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
xorg.conf file (9.00 KB, text/plain)
2010-03-04 17:05 UTC, Davin McCall 		no flags Details
X server log (xf86-video-ati) (51.54 KB, text/plain)
2010-03-04 17:06 UTC, Davin McCall 		no flags Details
X server log (xf86-video-radeonhd) (42.36 KB, text/plain)
2010-03-04 17:06 UTC, Davin McCall 		no flags Details
clear pll flags (549 bytes, patch)
2010-03-05 07:48 UTC, Alex Deucher 		no flags Details | Splinter Review
View All

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.