Bug 12843

Created attachment 12096 [details]
Complete Xorg log

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.

rhd_conntest output for various connectors used (I don't have anything to connect to svideo output):

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

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

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

DVI2
Checking connectors on 0x7183, 0x1028, 0x0D02  (@01:00:00):
  Load Detection: RHD_OUTPUT_NONE 
  HotPlug: RHD_HPD_1
  DDC: RHD_DDC_1

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.

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.

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.

Pushed. VGA connectors should work now.

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.

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.

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.

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.

(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 ?

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.

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.

Created attachment 12295 [details]
log of failing radeonhd startup on F8

(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 :-)

   http://koji.fedoraproject.org/koji/packageinfo?packageID=5156

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.

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.

Please try the latest version of our driver. It should work.

VGA works, DVI kind of works - it black outs the screen in random intervals for random time.

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

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...

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)

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?

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.

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 :)

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! ;-)