xf86-video-ati-6.13.2 scrambles 2560x1600 dual link DVI video on Radeon HD 4670. xf86-video-ati from git as of 2010.10.07 also has this problem. xf86-video-ati-6.13.1 is OK. Sorry I do not have time to do a git bisect right now, although I may try at some point if nobody beats me to it. In the meantime, I figure I should still report the bug now. When I try to set dual link mode (2560x1600) in xf86-video-ati-6.13.2 or the git version as of 2010 Oct. 7, I get what appears to be a bad video signal. Either the whole panel will display a rapidly changing or flickering image that looks somewhat similar to analog television static, or the left side of the panel will display this and the right side of the panel will display a blurry image of the frame buffer that I can still use. This problem occurs with user level mode setting. With kernel mode setting, the X server comes up solid black and the server log repeatedly says "Timeout trying to update memory controller settings", followed by "You will probably crash now...", but that too will be a separate bug report. I mention it here just indicate the "just run kernel mode setting" is unlikely to work for users with a configuration like mine, although I think that fixing the kernel mode setting issue and then saying "just run kernel mode setting" might be sufficient solution for other Linux users (although I am not sure about where that would leave users of other kernels, such as *BSD). Relevant lspci lines: $ lspci | grep VGA 02:00.0 VGA compatible controller: ATI Technologies Inc RV730XT [Radeon HD 4670] $ lspci -n -s 02:00.0 02:00.0 0300: 1002:9490
I hasten to add that my configuration is dual screen with DVI-0 attached to a 1920x1200 monitor and DVI-1 attached to the 2560x1600 monitor.
I should also mention that I tried booting with radeon.new_pll=0 on the command line as mentioned in bug 27470, and this did not fix the problem with xf86-video-ati-6.13.2.
Can you attach your xorg logs for both UMS and KMS and your dmesg for KMS? Also, what kernel are you using?
Created attachment 39261 [details] Kernel mode setting xf86-video-ati log
The computer I observed this problem on runs a 64-bit ("amd64") 2.6.36-rc7 kernel with 32-bit ("x86") user space. I have posted a log for kernel mode setting. The user mode setting log will follow shortly.
(In reply to comment #4) > Created an attachment (id=39261) [details] > Kernel mode setting xf86-video-ati log You aren't actually using KMS here, the driver still ends up loading in UMS mode even though you have the drm loaded in KMS mode: [ 14.823] (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch. [dri] This chipset requires a kernel module version of 1.17.0, [dri] but the kernel reports a version of 2.6.0.[dri] If using legacy modesetting, upgrade your kernel. [dri] If using kernel modesetting, make sure your module is [dri] loaded prior to starting X, and that this driver was built [dri] with support for KMS. [dri] Disabling DRI. make sure your ddx was built with KMS support and that the drm is loaded before starting X.
Created attachment 39269 [details] Xorg xf86-video-ati-6.13.2 user mode setting 2560x1600 scrambling Xorg.0.log file Here is a log of the X server with xf86-video-ati-6.13.2 + user mode setting scrambling the output when the video mode is set to 2560x1600. The server initially drives the 2560x1600 monitor at 1920x1200, which produces good video. Then doing something like "xrandr --output DVI-1 --mode 2560x1600" results in a the left half of the screen being completely scrambled and the right side being rather blurry, as if perhaps every other pixel had been transposed. Also, thanks for the advice about getting the X server to work under KMS. I will look into it.
UMS should be fixed in: 74fd2b91477106a26a2d9fb4b11c885910996041
Awesome! I did a "git pull" and rebuilt. Dual link now displays properly with user mode setting (and the kernel mode setting is apparently my own problem and, in any case, not the subject of this bug report). I confirm the bug is fixed. Please feel free to close this bug as "fixed." Thank you, Alex, for your super prompt and efficient analysis and fixing of this problem.
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.