Each version of the radeon driver after 6.6.193 fails to launch X on my system. The symptoms are a black screen and a blinking LED on my monitor. Another side effect is a very dark and almost unreadable (font) brightnes on the virtual terminals. I’m using a Radeon 9600 (RV350) with 256 of RAM and a AL1711 monitor from Acer. I did have no problems whatsoever with this driver before. Attached are 1) my xorg.conf, 2) Xorg.0.log for the working version 6.6.193, 3) Xorg.0.log for the failing stable version 6.8.0 and 4) Xorg.0.log for the GIT snapshot 38606b08 from 2008-03-10. Please ask for anything which might help solving this.
Created attachment 15253 [details] Xorg.0.log for the working version 6.6.193
Created attachment 15254 [details] Xorg.0.log of the failing version 6.8.0
Created attachment 15255 [details] Xorg.0.log of the failing version 6.8.0, GIT snapshot 38606b08
Created attachment 15256 [details] X.org configuration file
Your monitor does not appear to provide an edid, so the driver is not able to determine what modes it supports. You can override this with proper settings in your config. The setup of options has changed slightly with randr 1.2 support. This page should give you a good overview: http://www.intellinuxgraphics.org/dualhead.html replace your device and monitor sections with the following: Section "Device" Identifier "Radeon9600" Driver "radeon" BusID "PCI:1:0:0" #Option "AGPMode" "8" #Option "AGPFastWrite" "on" # Ouch! Kills X # Some tuning #Option "AccelDFS" "on" #Option "AccelMethod" "EXA" #Option "MigrationHeuristic" "greedy" #Option "RenderAccel" "on" #Option "FBTexPercent" "0" Option "Monitor-VGA-0" "AL1711" EndSection Section "Monitor" Identifier "AL1711" Option "DPMS" HorizSync 30-83 VertRefresh 55-75 Modeline "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync Modeline "1280x1024R" 90.75 1280 1328 1360 1440 1024 1027 1034 1054 +hsync -vsync #Option "PreferredMode" "1280x1024_60.00" Option "PreferredMode" "1280x1024R" EndSection If you still have problems, try switching the "PeferredMode" lines.
(In reply to comment #5) > Section "Monitor" > Identifier "AL1711" > Option "DPMS" > HorizSync 30-83 > VertRefresh 55-75 > Modeline "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 > 1063 -hsync +vsync > Modeline "1280x1024R" 90.75 1280 1328 1360 1440 1024 1027 1034 1054 > +hsync -vsync > #Option "PreferredMode" "1280x1024_60.00" > Option "PreferredMode" "1280x1024R" > EndSection > > If you still have problems, try switching the "PeferredMode" lines. I had to do that. The 1280x1024R fails just like before, the other one works. Thanks for that so far. (I only have to get to understand all those weird numbers now.) One more problem arised now: The fonts/graphics are a bit blurry in the edges and the right part of the screen, a problem which only appeared on VT so far. Additionally the font of the VT is still dark and almost unreadable. Do you have another good idea for these problems?
(In reply to comment #6) > I had to do that. The 1280x1024R fails just like before, the other one works. > Thanks for that so far. (I only have to get to understand all those weird > numbers now.) those are modelines generated with cvt. the numbers are the timing used to program the crtc and pixel clock. > > One more problem arised now: The fonts/graphics are a bit blurry in the edges > and the right part of the screen, a problem which only appeared on VT so far. > Additionally the font of the VT is still dark and almost unreadable. Do you > have another good idea for these problems? > Can you take picture? Is this an LCD or CRT monitor? If LCD, what's it's native mode?
looks like your monitor ran at 75 Hz in 6.6.193. try adding this modeline: Modeline "1280x1024_75.00" 138.75 1280 1368 1504 1728 1024 1027 1034 1072 -hsync +vsync Option "PreferredMode" "1280x1024_75.00" You can use cvt to generate custom modes: cvt <x> <y> <refresh> e.g.: $ cvt 1280 1024 75 # 1280x1024 74.90 Hz (CVT 1.31M4) hsync: 80.30 kHz; pclk: 138.75 MHz Modeline "1280x1024_75.00" 138.75 1280 1368 1504 1728 1024 1027 1034 1072 -hsync +vsync
(In reply to comment #7) > (In reply to comment #6) > > One more problem arised now: The fonts/graphics are a bit blurry in the edges > > and the right part of the screen, a problem which only appeared on VT so far. > > Additionally the font of the VT is still dark and almost unreadable. Do you > > have another good idea for these problems? > > > > Can you take picture? Unfortunately not since it’s a hardware issue. Providing you a shot using my digital camera won’t help much either, I guess. > Is this an LCD or CRT monitor? It’s a LCD monitor. > If LCD, what's it's native mode? The native resolution is 1280×1024, as I am using correctly, the vertical refresh rate is 75Hz, the horizontal one is 80kHz. The video bandwidth seems to be 135MHz. It’s in German, but a lot of details are written here: <http://www.dooyoo.de/tft-monitor/acer-al1711-et-l170a-189/details/>, HTH(In reply to comment #8) > looks like your monitor ran at 75 Hz in 6.6.193. try adding this modeline: > Modeline "1280x1024_75.00" 138.75 1280 1368 1504 1728 1024 1027 1034 1072 > -hsync +vsync > Option "PreferredMode" "1280x1024_75.00" I tried that and X again fails to launch with this line. Also setting 75Hz manually using Xfce’s setting manager after launching the X session with the working line afterwards makes the monitor behave buggy again. > You can use cvt to generate custom modes: Thanks for this tip.
Created attachment 15259 [details] Xorg.0.log of the failing version 6.8.0 and Modeline for 75Hz The Xorg.0.log from using the 75Hz Modeline. The following looks a bit suspicious to me: > (WW) RADEON(0): Option "PreferredMode" is not used
Any further ideas on this? I can use the current setup temporarily but those blurry fonts and graphics will hurt my eyes in the long term. In the worst case I’d have to revert to 6.6.193 and stay with that one forever. I really don’t like this solution.
(In reply to comment #11) > Any further ideas on this? I solved one of the remaining problems (blurry fonts and graphics) now by using the following Modeline taken from the Xorg.0.log of the working old version 6.6.193: > Modeline "1280x1024_60.00" 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync It seems all the numbers are important, changing -hsync to +hsync in the _60.00 line taken from cvt’s output doesn’t change any thing. The _75 line from the old log doesn’t work whatsoever but I don’t care about that, since I don’t seem to need it. The only problem left are the still persistent dark fonts on VT. However, I don’t really see how X is related to VT except that it can be run on one or more of them. How does X influence VT it doesn’t use? (VT 1 to 6 here)
(In reply to comment #12) > (In reply to comment #11) > > Any further ideas on this? > > I solved one of the remaining problems (blurry fonts and graphics) now by using > the following Modeline taken from the Xorg.0.log of the working old version > 6.6.193: > > > Modeline "1280x1024_60.00" 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync > > It seems all the numbers are important, changing -hsync to +hsync in the _60.00 > line taken from cvt’s output doesn’t change any thing. > LCD monitors in particular are very picky about what mode they like. Usually we are able to get the mode via edid. > The only problem left are the still persistent dark fonts on VT. However, I > don’t really see how X is related to VT except that it can be run on one or > more of them. How does X influence VT it doesn’t use? (VT 1 to 6 here) > If they are dark before starting X, then it's a bios issue, if they are dark only after switching to another VT after starting X, then there's some problem with how we save/restore state for VT switches.
(In reply to comment #13) > (In reply to comment #12) > > The only problem left are the still persistent dark fonts on VT. However, I > > don’t really see how X is related to VT except that it can be run on one or > > more of them. How does X influence VT it doesn’t use? (VT 1 to 6 here) > > > > If they are dark before starting X, then it's a bios issue, if they are dark > only after switching to another VT after starting X, then there's some problem > with how we save/restore state for VT switches. So the latter must be the case here. What can I do? Can I do anything at all about this?
(In reply to comment #14) > > If they are dark before starting X, then it's a bios issue, if they are dark > > only after switching to another VT after starting X, then there's some problem > > with how we save/restore state for VT switches. > > So the latter must be the case here. What can I do? Can I do anything at all > about this? > These kind of things are tough to track down. Take a look at RADEONRestore() in radeon_driver.c and try adjusting the order in which things are restored. Restoring the vga registers before the crtc registers may help.
(In reply to comment #15) > (In reply to comment #14) > > > If they are dark before starting X, then it's a bios issue, if they are dark > > > only after switching to another VT after starting X, then there's some problem > > > with how we save/restore state for VT switches. > > > > So the latter must be the case here. What can I do? Can I do anything at all > > about this? > > > > These kind of things are tough to track down. Take a look at RADEONRestore() > in radeon_driver.c and try adjusting the order in which things are restored. > Restoring the vga registers before the crtc registers may help. Phew. I’m know quite a bit about C, but understanding foreign code and modifying it so that it still works is pretty hard. You wouldn’t be so kind to create a patch which does this reordering, would you?
Created attachment 15345 [details] [review] possible fix see if this works.
(In reply to comment #17) > Created an attachment (id=15345) [details] > possible fix Thanks for creating the patch. > see if this works. It works like a charm. The font is now as bright as before and I see no side effects due to the code reordering. So this really is a fix, thanks a lot. If the patch gets approved and merged into main tree, the whole issue is fixed for me. Once again, thank you very much for your help.
(In reply to comment #18) > (In reply to comment #17) > > Created an attachment (id=15345) [details] [details] > > possible fix > > Thanks for creating the patch. > > > see if this works. > > It works like a charm. The font is now as bright as before and I see no side > effects due to the code reordering. So this really is a fix, thanks a lot. The problem is I changed the ordering originally to fix a similar issue for someone else; however it seems as though the change has caused more problems than it fixed so, I suppose I'll just change it back.
Can you try one more thing? Does this option help: Option "VGAAccess" "False"
(In reply to comment #20) > Can you try one more thing? Does this option help: > > Option "VGAAccess" "False" Yes, this also seems to fix the problem. I guess this is a better solution since you can keep the current fix for other systems.
Closing this report with NOTABUG since the issue is based on my wrong configuration and not a but in X.
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.