I have been trying to get my Dell 2407FWP to work on my powerbook, however the image is not stable at resolutions above 1024x768. This is way lower than the native resolution of 1920x1200. Driving the display at 1920x1200 does work, however the image becomes wobbly. This disturbance makes it very uncomfortable to read text on the display. When I display the X-diagnosis grid the disturbance becomes even more apparent and manifests itself as blurry horizontal bars that vary in position and intensity. The display works fine when using OS/x or an older powerbook with a Radeon 9000 card instead of the Mobility Radeon 9600 M10. The display is connected via VGA, since the driver currently doesn't support DVI. My X.org version is 7.1.0. Two weeks ago I compiled the newest driver from git, but the result was the same. I've tried every possible configuration I could think of that were capable of driving the external display. The attached config contains some extra information about the various things I tried (N.B. the exact same config works on another powerbook with the radeon 9000 card). The most notable is the fact that switching the explicit modelines on does really improve the overall quality. When I let X decide not even 1024x768 is stable, and the resolutions above that are a lot worse. When I do enable the modelines the amount of disturbance lessens in every resolution. In 1024x768 it even causes the image to be totally clear. I have attached both my xorg.conf config, and two log files. The first showing what happens without the modelines, the second shows what happens with the modelines. I'd be happy to provide any extra information you need.
Created attachment 8456 [details] Configuration file (xorg.conf) Configuration used.
Created attachment 8457 [details] Log with modelines enabled Logfile with modelines.
Created attachment 8458 [details] Log without modelines enabled. Log without modelines enable.
Created attachment 8459 [details] Photo of display This photo shows clearly the horizontal bars that are scrolling over the screen.
(In reply to comment #0) > The display works fine when using OS/x or an older powerbook with a Radeon 9000 > card instead of the Mobility Radeon 9600 M10. The display is connected via VGA, > since the driver currently doesn't support DVI. My X.org version is 7.1.0. Two > weeks ago I compiled the newest driver from git, but the result was the same. I assume when you say it doesn't happen with OS/X then you're using also VGA output? > I've tried every possible configuration I could think of that were capable of > driving the external display. The attached config contains some extra > information about the various things I tried (N.B. the exact same config works > on another powerbook with the radeon 9000 card). The most notable is the fact > that switching the explicit modelines on does really improve the overall > quality. When I let X decide not even 1024x768 is stable, and the resolutions > above that are a lot worse. When I do enable the modelines the amount of > disturbance lessens in every resolution. In 1024x768 it even causes the image to > be totally clear. It is not surprising the reduced blanking modelines help, since vga outputs from notebooks are known to be generally not really good enough for clear output in high resolutions (though I don't know how well apple or specifically this notebook does). (And in fact the pixel clock is above the monitor's advertized maximum without it in 1920x1200). I'd have said it's just a not very high quality vga output, maybe coupled with a cable which degrades signal quality further, and the input circuitry in the monitor could make a difference too. However, if this works with OS/X, it apparently must be something else as timings used by OS/X are likely the same (though I'm not sure about sync polarity). I'll wonder, is it possible that using "wrong" reference divider etc. degrades signal quality (as those are defaulted since obviously your chip doesn't have a pc bios)? Might be something else though.
(In reply to comment #5) > It is not surprising the reduced blanking modelines help, since vga outputs from > notebooks are known to be generally not really good enough for clear output in > high resolutions (though I don't know how well apple or specifically this > notebook does). (And in fact the pixel clock is above the monitor's advertized > maximum without it in 1920x1200). > I'd have said it's just a not very high quality vga output, maybe coupled with a > cable which degrades signal quality further, and the input circuitry in the > monitor could make a difference too. However, if this works with OS/X, it > apparently must be something else as timings used by OS/X are likely the same > (though I'm not sure about sync polarity). I would have to concurr that the fact that it works flawlessly both using OS/X and another (a bit older) powerbook rules out the fact that the hardware is responsible. Furthermore, and I probably should have mentioned this before but I forgot, the modeline that is included is pulled directly from the "additional video modes" EDID information and has the correct (I checked the manual) sync polarity. In addition, this exact modeline works for other people. > I'll wonder, is it possible that > using "wrong" reference divider etc. degrades signal quality (as those are > defaulted since obviously your chip doesn't have a pc bios)? Might be something > else though. When comparing the log with the other powerbook's log we find almost no differences, one that comes to mind now is the following. In my log we find: (II) RADEON(0): Probed PLL values: xtal: 27.000000 Mhz, sclk: 391.500000 Mhz, mclk: 202.500000 Mhz while on the other one: (II) RADEON(0): Probed PLL values: xtal: 27.000000 Mhz, sclk: 200.250000 Mhz, mclk: 200.250000 Mhz I don't know whether this is relevant. The different value in sclk probably means my card is faster, however, the mclk value seems to differ more in my case. Hope this helps.
(In reply to comment #6) > I would have to concurr that the fact that it works flawlessly both using OS/X > and another (a bit older) powerbook rules out the fact that the hardware is > responsible. No, that it works with a powerbook with an older radeon 9000 doesn't really tell you anything, it is possible older generation has good quality output and newer one has not. But yes if that works with OS/X using VGA that rules it out. > When comparing the log with the other powerbook's log we find almost no > differences, one that comes to mind now is the following. In my log we find: Actually, I think I was wrong assuming the non-pcbios values could be problematic. These are still probed and not defaults, they should work fine. If you tried with git before 2007-01-03, could you retry? There was a fix for bogus mode regs initialization, not sure if it would have caused trouble with vga, and that bug shouldn't have been there with stock xorg 7.1 ati driver, but you never know...
(In reply to comment #7) > Actually, I think I was wrong assuming the non-pcbios values could be > problematic. These are still probed and not defaults, they should work fine. > If you tried with git before 2007-01-03, could you retry? There was a fix for > bogus mode regs initialization, not sure if it would have caused trouble with > vga, and that bug shouldn't have been there with stock xorg 7.1 ati driver, but > you never know... The build was of 2007-01-07 so I would think the fix was included. I can build the newest git driver if you want?
(In reply to comment #8) > The build was of 2007-01-07 so I would think the fix was included. I can build > the newest git driver if you want? No, that's new enough, I don't think there are any changes since then which might help.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
This should work correctly (even DVI) with the latest driver from ati git if you use one of the following options: Option "MacModel" "powerbook" or Option "MacModel" "powerbook-duallink" The only difference is whether your powerbook uses the internal (single link) tmds controller or an external (possibly dual link) TMDS controller. Please reopeon if you are still having issues.
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.