Bug 23901 - radeon KMS sends no input signal to LCD (regression in 2.6.31)
Summary: radeon KMS sends no input signal to LCD (regression in 2.6.31)
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: Other Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-13 09:03 UTC by Adam K Kirchhoff
Modified: 2009-11-09 17:01 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
'dmesg | grep drm' from Slackware 13 (2.48 KB, text/plain)
2009-09-13 09:03 UTC, Adam K Kirchhoff
no flags Details
'dmesg | grep drm' from F11 (412 bytes, text/plain)
2009-09-13 09:04 UTC, Adam K Kirchhoff
no flags Details
Xorg.0.log from Slack 13 (48.91 KB, text/plain)
2009-09-13 09:04 UTC, Adam K Kirchhoff
no flags Details
Xorg.0.log from from F11 (126.41 KB, text/plain)
2009-09-13 09:05 UTC, Adam K Kirchhoff
no flags Details
'xrandr --verbose' from slack 13 (8.20 KB, text/plain)
2009-09-13 09:05 UTC, Adam K Kirchhoff
no flags Details
'xrandr --verbose' from F11 (8.00 KB, text/plain)
2009-09-13 09:05 UTC, Adam K Kirchhoff
no flags Details
'dmesg | grep drm' from 2.6.31, with just the working LCD attached. (2.43 KB, text/plain)
2009-09-13 09:13 UTC, Adam K Kirchhoff
no flags Details
Xorg.0.log file with working correctly with KMS enabled, using the HD3450 (56.92 KB, text/plain)
2009-09-23 17:02 UTC, Adam K Kirchhoff
no flags Details

Description Adam K Kirchhoff 2009-09-13 09:03:47 UTC
Created attachment 29484 [details]
'dmesg | grep drm' from Slackware 13

I have Fedora 11 on one drive, using 2.6.30.5-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.
Comment 1 Adam K Kirchhoff 2009-09-13 09:04:09 UTC
Created attachment 29485 [details]
'dmesg | grep drm' from F11
Comment 2 Adam K Kirchhoff 2009-09-13 09:04:39 UTC
Created attachment 29486 [details]
Xorg.0.log from Slack 13
Comment 3 Adam K Kirchhoff 2009-09-13 09:05:03 UTC
Created attachment 29487 [details]
Xorg.0.log from from F11
Comment 4 Adam K Kirchhoff 2009-09-13 09:05:24 UTC
Created attachment 29488 [details]
'xrandr --verbose' from slack 13
Comment 5 Adam K Kirchhoff 2009-09-13 09:05:50 UTC
Created attachment 29489 [details]
'xrandr --verbose' from F11
Comment 6 Adam K Kirchhoff 2009-09-13 09:12:37 UTC
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.
Comment 7 Adam K Kirchhoff 2009-09-13 09:13:28 UTC
Created attachment 29490 [details]
'dmesg | grep drm' from 2.6.31, with just the working LCD attached.
Comment 8 Adam K Kirchhoff 2009-09-15 13:29:41 UTC
After a brief discussion with airlied on #radeon, I checked the contents of /sys/class/drm/card0-*/dpms and both monitors had "On".
Comment 9 Adam K Kirchhoff 2009-09-23 12:12:41 UTC
This problem persists with drm-next as of September 23rd.

Adam
Comment 10 Adam K Kirchhoff 2009-09-23 13:53:25 UTC
An attempted force dpms cycle (with 'xset dpms force suspend'), as suggested by Alex D., did not bring the LCD back on-line.

Comment 11 Adam K Kirchhoff 2009-09-23 17:01:15 UTC
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.

Adam
Comment 12 Adam K Kirchhoff 2009-09-23 17:02:04 UTC
Created attachment 29820 [details]
Xorg.0.log file with working correctly with KMS enabled, using the HD3450
Comment 13 Adam K Kirchhoff 2009-09-24 03:23:20 UTC
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).

Comment 14 Adam K Kirchhoff 2009-09-24 13:29:01 UTC
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.
Comment 15 Adam K Kirchhoff 2009-09-24 17:52:13 UTC
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.
Comment 16 Adam K Kirchhoff 2009-11-09 17:01:03 UTC
Updated to 2.6.31.5 today and it works great again.  Thanks all.


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.