Created attachment 29484 [details]
'dmesg | grep drm' from Slackware 13
I have Fedora 11 on one drive, using 18.104.22.168-43, and running KMS + Xorg wonderfully on my x850. Both monitors are detected and initialized at their native resolution. This is an LCD at 1280x1024 and a CRT at 1600x1200. As expected, the console on the CRT only uses 1280x1024 of the screen, even though the monitor is being run at 1600x1200.
I have Slackware 13 on another drive, and compiled the 2.6.31 kernel this morning, enabling radeon KMS by default. I updated drm (with the experimental radeon API), Mesa, and xf86-video-ati. The computer boots up, and as soon as the framebuffer kicks in, the LCD displays "no input signal" and turns off after a few seconds. The CRT is set to 1600x1200, and only uses 1280x1024 of the screen, as if the console driver knows that the LCD is attached and is running at 1280x1024. I can start X, but only the CRT is usable. The LCD remains asleep. Even if I use xrandr to adjust the resolution on the LCD, it doesn't flicker and doesn't display anything.
I am initially attaching 6 files. 'dmesg | grep drm' from both F11 and slackware 13, Xorg.0.log from both distributions, and 'xrandr --verbose' from both distributions. The only difference between the two distributions is that F11 is 32 bit and Slackware 13 is 64 bit.
Created attachment 29485 [details]
'dmesg | grep drm' from F11
Created attachment 29486 [details]
Xorg.0.log from Slack 13
Created attachment 29487 [details]
Xorg.0.log from from F11
Created attachment 29488 [details]
'xrandr --verbose' from slack 13
Created attachment 29489 [details]
'xrandr --verbose' from F11
I ran one further test. I unhooked the CRT, rebooted, and the LCD initialized just fine on 2.6.31. So the problem only happens when both monitors are hooked up.
Created attachment 29490 [details]
'dmesg | grep drm' from 2.6.31, with just the working LCD attached.
After a brief discussion with airlied on #radeon, I checked the contents of /sys/class/drm/card0-*/dpms and both monitors had "On".
This problem persists with drm-next as of September 23rd.
An attempted force dpms cycle (with 'xset dpms force suspend'), as suggested by Alex D., did not bring the LCD back on-line.
This same combination of monitors works fine with an HD3450 and drm-next. The LCD stays on when the framebuffer kicks in. Attaching Xorg.0.log file from the HD3450.
Created attachment 29820 [details]
Xorg.0.log file with working correctly with KMS enabled, using the HD3450
The same x850 works fine with KMS enabled in another box with a viewsonic va902b and a viewsonic va1903wmb. With this combination, both monitors switch to their preferred resolution (1280x1024 on one, 1440x900 on the other).
Using an x1900, with the same monitors, and I get the same problem with the CRT. So, to summarize, it happens with the x850 (what I normally use), the x1900, but works fine with the HD3450.
This is mostly resolved. As soon as I swapped monitors on the two DVI ports, it started working. The LCD switchest to 1280x1024 and the CRT switches to (a flickering) 1600x1200. I did previously test this last week, and it did not work at that time (instead, both monitors were stuck in clone mode). However, I have since updated to drm-next.
If I switch back and reboot, though, the LCD goes blank. Alex remarked that he would try a test with a similar card to see if he can reproduce the problem.
Updated to 22.214.171.124 today and it works great again. Thanks all.