Bug 12843 - Cannot map connectors on Radeon X1300
Summary: Cannot map connectors on Radeon X1300
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/radeonhd (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Luc Verhaegen
QA Contact: Xorg Project Team
Depends on:
Reported: 2007-10-17 19:29 UTC by Michal Čihař
Modified: 2007-11-26 01:08 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Complete Xorg log (19.04 KB, text/x-log)
2007-10-17 19:30 UTC, Michal Čihař
no flags Details
Log with current git (24.52 KB, text/x-log)
2007-10-17 19:54 UTC, Michal Čihař
no flags Details
Log with wrong mode detection (51.97 KB, text/x-log)
2007-10-18 17:51 UTC, Michal Čihař
no flags Details
log of failing radeonhd startup on F8 (20.94 KB, text/x-log)
2007-11-01 07:12 UTC, Mads Kiilerich
no flags Details
Log with blackouts (52.08 KB, text/plain)
2007-11-21 00:36 UTC, Michal Čihař
no flags Details

Description Michal Čihař 2007-10-17 19:29:35 UTC
I just got this error when trying to use radeonhd driver, if you need whatver information feel free to ask me.

(WW) RADEONHD(0): Unknown card detected: 0x7183:0x1028:0x0D02.
        Your card might not work or might not work optimally.
        To rectify this, please contact MAILINGLIST.
        Include your X log and the full name of the device.
(--) RADEONHD(0): Detected an RV515 on an unidentified card
(EE) RADEONHD(0): Cannot map connectors on an unknown card!
To help rectify this, please send your X log to
        or file a bug for the radeonhd component
        of the X.Org product at bugs.freedesktop.org.

I'm currently using version in Debian, called 0.0.1+git20070920 so I guess it's a git snapshot.
Comment 1 Michal Čihař 2007-10-17 19:30:26 UTC
Created attachment 12096 [details]
Complete Xorg log
Comment 2 Michal Čihař 2007-10-17 19:54:45 UTC
Created attachment 12097 [details]
Log with current git

I rerun xserver with current radeonhd git code. It is much better, it detects monitor, prints EDID, shows information about available connectors ... and then it fails with "Failed to detect a connected monitor", for more details see attached log.
Comment 3 Michal Čihař 2007-10-17 20:24:37 UTC
rhd_conntest output for various connectors used (I don't have anything to connect to svideo output):

Checking connectors on 0x7183, 0x1028, 0x0D02  (@01:00:00):
  Load Detection: RHD_OUTPUT_DACA
  HotPlug: RHD_HPD_NONE 

Checking connectors on 0x7183, 0x1028, 0x0D02  (@01:00:00):
  Load Detection: RHD_OUTPUT_DACB
  HotPlug: RHD_HPD_NONE 

Checking connectors on 0x7183, 0x1028, 0x0D02  (@01:00:00):
  Load Detection: RHD_OUTPUT_NONE 
  HotPlug: RHD_HPD_0

Checking connectors on 0x7183, 0x1028, 0x0D02  (@01:00:00):
  Load Detection: RHD_OUTPUT_NONE 
  HotPlug: RHD_HPD_1
Comment 4 Luc Verhaegen 2007-10-18 07:50:16 UTC
This HPD to output mapping is highly irregular.

Could this be the dell card with the DMS-59 connector: http://en.wikipedia.org/wiki/DMS-59

The atombios connector table says that this card has 2 dvi-i connectors instead of one DMS-59. DMS-59, as a seperate connecter would've posed an interesting problem on its own though.

It would seem that the DMS-59->2xVGA adapter is broken. If it would work in a manner similar to a DVI-I->VGA adapter, it would raise the HPD pins. It apparently doesn't do so.

This means that i will need to work around this through our card-id table, and map the connectors manually.

This, sadly, will not provide you with working DVI-D outputs yet, as the load detection on TMDSA seems to fail. I will need to look into this issue with the hardware in hands, but i will provide a workaround (as specified in the dvi specs) when i implement TMDS on the LVTMA block.
Comment 5 Michal Čihař 2007-10-18 08:10:59 UTC
Yes, it's a Dell PC with such connector, but I simply did not know it :-). I used DMS-59 to 2xDVI and DMS-59 to 2xVGA reductions I got with the PC, in all cases connected to same monitor.

Would a ssh access to the PC help you? I'm still not sure whether I can actually set it up this way, but I can try.
Comment 6 Luc Verhaegen 2007-10-18 08:20:04 UTC
No, ssh access is not necessary... We're looking into getting this hardware, as it is quite interesting ;)

I will soon provide a workaround in our git tree, it is the next thing on my plate now :) This will be right after i am finished reviewing the code i have just written, and i will give you a heads up here about it when it happens.
Comment 7 Luc Verhaegen 2007-10-18 09:58:10 UTC
Pushed. VGA connectors should work now.
Comment 8 Michal Čihař 2007-10-18 17:51:01 UTC
Created attachment 12113 [details]
Log with wrong mode detection

Thanks! Now I can use radeonhd driver. The only small problem left is that it did not automatically detect correct resolution and falled back to 800x600. Even vesa driver can detect 1600x1200 in my properly :-). Adding monitor refresh ranges allowed me to use 1600x1200...

I'm attaching current log in case it will be helpful for you.
Comment 9 Michal Čihař 2007-10-18 18:47:32 UTC
Okay the whole problem comes from having monitor section in xorg without defining sync ranges. radeonhd driver in this case creates some low/safe default/whatever ranges, which simply do not allow any reasonable resolution nowadays. I think that when there are no sync ranges defined, it should use DDC information, same as other drivers do.
Comment 10 Luc Verhaegen 2007-10-19 03:02:45 UTC
Nah, no monitor section should be created at all.

This is just some transitional pain, which we will work around (for distributions that feel they do need to create a useless monitor section) and which people should get used to.

Maybe i should add a warning to the driver, when a configured monitor is found, to reduce the confusion.
Comment 11 Michal Čihař 2007-10-19 03:30:29 UTC
Just adding some line telling that it is using builtin ranges would lower confusion. In fact I didn't realize real cause of this till reading the code.
Comment 12 Mikael FRECHE 2007-10-30 10:31:44 UTC
(In reply to comment #7)
> Pushed. VGA connectors should work now.

I've got a Dell Optiplex with Radeon HD 2400 XT and DMS-59 connector.

The workaround for X1300 in rhd_id.c works fine for me, since I adapted it to my video card.

I added the line :
> { 0x94C1, 0x1028, 0x0D02, "Dell Radeon HD 2400 XT", DMS59},
in the rhdCards table.

It works fine.

Can anybody modify the repository's source ?
Comment 13 Luc Verhaegen 2007-10-31 05:58:44 UTC
This will get a better solution soon, where the device ids will be known, but where there will be a flags entry to this structure, which will have RHD_CARD_FLAG_DMS59.

This will then, when a connector turns up nothing in HPD, still attempt load detection on the DVI connectors DACs, making up for the badly implemented VGA adapter.
Comment 14 Mads Kiilerich 2007-11-01 07:10:49 UTC
Running Fedora 8 I just tested xorg-x11-driver-video-radeonhd-0.0.1-71.1 built on
 * Tue Oct 30 2007 sndirsch@suse.de
 - coommit 972e21bb48771050cbf35a8ef9c36a13fff27d68
(VERY kind of you to provide a fedora yum repo on opensuse.org!)

Have a Dell with RV516 X1300 pro and a splitter cable like the one mentioned, and I got something that looks like the problem Michal had. I assume the mentioned fix is included in the rpm, but it doesn't work for me. I will attach the Xorg.0.log. (It seems to be very similar to the one on http://lists.opensuse.org/radeonhd/2007-11/msg00000.html)

Let me know if I can help somehow.
Comment 15 Mads Kiilerich 2007-11-01 07:12:03 UTC
Created attachment 12295 [details]
log of failing radeonhd startup on F8
Comment 16 Hans Ulrich Niedermann 2007-11-01 07:48:35 UTC
(In reply to comment #14)
> Running Fedora 8 I just tested xorg-x11-driver-video-radeonhd-0.0.1-71.1 built
> on
>  * Tue Oct 30 2007 sndirsch@suse.de
>  - coommit 972e21bb48771050cbf35a8ef9c36a13fff27d68
> (VERY kind of you to provide a fedora yum repo on opensuse.org!)

I have no idea why that one has a "0.0.1" version number, but I'd like to plug the Fedora Koji page on the Fedora package here :-)


Those ".fc9" builds are currently basically F8 packages, and downloadable binary RPMs for i386, x86_64, ppc, and ppc64 are just two clicks away from that page.

Comment 17 Luc Verhaegen 2007-11-02 01:58:38 UTC
Mads: you are using a slightly older version of the driver; there is a different fix for the DMS-59 connector now. This will not fix the issue you are having with your DVI links, but will still make your VGA connections work.
Comment 18 Luc Verhaegen 2007-11-19 10:36:53 UTC
Please try the latest version of our driver. It should work.
Comment 19 Michal Čihař 2007-11-20 21:11:39 UTC
VGA works, DVI kind of works - it black outs the screen in random intervals for random time.
Comment 20 Luc Verhaegen 2007-11-21 00:10:06 UTC
Can you describe more about these blackouts? How frequent is this, how and when does it come back up?

Can you provide me with a log of running Xorg -logverbose 7
Comment 21 Michal Čihař 2007-11-21 00:14:45 UTC
I guess it's just shorter than second - I see the picture and I see the black screen. Switching back to console brings me back picture.

I will reboot to enable DVI on console and give you logs...
Comment 22 Michal Čihař 2007-11-21 00:36:24 UTC
Created attachment 12662 [details]
Log with blackouts

Attaching log. If you want to get rough idea how it looks like, here is video from my cell phone: http://tmp.cihar.com/Video003.avi (will be available for one month there)
Comment 23 Luc Verhaegen 2007-11-21 00:51:50 UTC
Wow. 162Mhz on a single link is close to the limit. This could be the issue here.

Please use:
 Option "ForceReduced" "True"
in your device section.

And use the following for your M odes directive in your Display subsection of your Screen section:
  Modes "1600x1200R"

This will create a reduced blanking mode which will bring that frequency down to about 130Mhz.

This is a Samsung SyncMaster 204B, right? As there seem to be more issues with bandwidth with these monitors.

Also: the driver is unable to find anything on EDID for the second connector, is this correct?
Comment 24 Michal Čihař 2007-11-21 01:02:16 UTC
I use only single connector on DMS-59. And yes, it is Samsung SyncMaster 204B.

I'm leaving work right now, will test your ideas tomorrow.
Comment 25 Luc Verhaegen 2007-11-21 01:07:32 UTC
Aha, so it is an issue with the monitor. And this exact monitor is known to not accept its preferred mode, as the bandwidth is too high :)

The provided extra configuration will then fix your issue :)
Comment 26 Mads Kiilerich 2007-11-26 01:08:18 UTC
I can confirm that my Dell with RV516 X1300 pro and a splitter cable now works fine. Thanks!

Tested with f5ffe41a6c1ffa9418782b7059b075da06e7c496  Fri, 23 Nov 2007 17:36:58 +0000 (18:36 +0100)

Now I'm looking forward to 2D acceleration! ;-)

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.