Bug 431691

Created attachment 294111 [details]
Xorg.0.log

Which version of the driver this Xorg.0.log corresponds to?

It should be xorg-x11-drv-ati-6.7.197-1.fc9.i386 . I did have an xorg.conf file when that log was created.
The xorg.conf file attempts to associate the monitor with the DVI port. I needed this for things to work on F8. Only the driver in updates worked for me. The original version with F8 and the last couple to show up in updates testing didn't work.

As another data point, this combination does work with the vesa driver.

Still not working in xorg-x11-drv-ati-6.7.197-3.fc9.i386.
I have been also noticing that the vesa driver doesn't always start either. It
appears to be random when starting. Once it fails I seem to need to reboot. Once
it is working things continue to work as long as I don't stop X. This might be
related or it might be another bug.

I tested xorg-x11-drv-ati-6.8.0-1.fc9.i386 and it still has the same problem.
When trying to fall back to the vesa driver without rebooting, I found it
annoyingly keeps trying for a long time and does not wait very long between
retries. This makes it a pain to enter telinit 3 ibto a vt to get it to stop.
(You need to repeated type in each character until it finally lands in the gap
between retries.) Either it should give up after a few tries or it should start
waiting longer between retries.

Since the Vesa driver was failing consistantly today I went back to this today
and took a look at the source. I found some stale commented out code in
radeon_output.c that used to set the monitor type to MT_DFP in some cases where
DDC info wasn't provided. I hacked this to just do that if it got there and my
setup works. While there is probably some reason this was done so that doing
what I did is probably a bad idea in general, this probably was the area that
was changed that broke things for me (though I didn't try to match up when it
changed versus when things broke).
At least I have a reasonable work around I can use for the time being.
In case it matters, I was playing with xorg-x11-drv-ati-6.8.0-4.fc9.

I tried out xorg-x11-drv-ati-6.8.0-5.fc9.i386, but as expected from the comments
this didn't fix my problem and I needed to reapply my hack to get it to work for me.

I tracked down the commit that commented out the code that seems to be giving me
a problem. It was commit:
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commit;h=fe2f7a09050fb7a345a1f52239f8f3c4f1053891
It has a description of:
Merge branch 'master' into agd-atom-merge
Which doesn't say a lot about why it was done.
If I try to fix up the code so that it will compile and seems to work for me is
there a chance this is something that might be turned back on?
The code snippet is:
    } /*else if (radeon_output->type == OUTPUT_DVI) {
        if (radeon_output->TMDSType == TMDS_INT) {
            if (INREG(RADEON_FP_GEN_CNTL) & RADEON_FP_DETECT_SENSE)
                MonType = MT_DFP;
        } else if (radeon_output->TMDSType == TMDS_EXT) {
            if (INREG(RADEON_FP2_GEN_CNTL) & RADEON_FP2_DETECT_SENSE)
                MonType = MT_DFP;
        }
        }*/

With 6.8.0-9 adding MonType = MT_DFP where the above code was doesn't work. So
changing that probably isn't the right place. For now I'll just keep using a
modified 6.8.0-5 and testing new ones as they come out. As I get time I'll try
to understand the code a bit more and see if I can figure out a better change.

I tried out xorg-x11-drv-ati-6.8.0-14.fc9.i386.rpm and am still seeing the same
problem.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I tried out xorg-x11-drv-ati-6.8.0-19.fc9.i386. Still does not output to the dvi
port. I went and changed it to use a MonType of MT_DFP when there is no montype
and that makes it work for me, but isn't a real fix.

I upgraded this system to rawhide and saw the same problem in xorg-x11-drv-ati-6.9.0-7.fc10.i386. However hacking the driver to use MT_DFP instead of MT_NONE also continued to work.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This has become moot, at least for the time being. I scronged another computer with a video card that has only DVI outputs so I needed to swap monitors. So I am now using a different 2010X that has a vga input connector instead of a dvi connector on the machine with the radeon 9200 card. It now works with the standard driver. The scronged machine has an nVidia card in it, so any problems with EDID won't be relevant to the ati driver.

How about Fedora 11 or Fedora 12 Snap1?

The machine I swapped with has an nvidia card and is running rawhide. It doesn't have the above problem, but does have a different one that I have filed a big for.
I am running F11 on the affected machine and am still using nomodeset because of a separate issue with the ati driver not working. But since I am now connecting to the VGA port I get output.

So, shall we resolve this bug as fixed or rather update summary to reflect it's still relevant in Fedora 11?

I believe it is still relevant. I haven't seen any comments on updates suggesting this issue got fixed. I forget when exactly I switched that machine over to F11 rawhide, but it's likely I still had the old monitor in place for some of the time F11 was in development.

Bruno, I'm not sure if KMS is working right with RV250, but this might be worth retrying (even with KMS disabled) if you can.

You can always use one of the nightly composes:
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/

The radeon driver is working for 3d (no nomodeset) in F12.And it has been working well (without regular crashes) for about a week. Though that was really a separate bug.
I switched monitors around, so I am using the VGA output now. So I don't know whether or not the not sending output to the DVI port when the attached monitor doesn't do proper EDID but is otherwise detected bug is still present.

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Improving summary.

---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[This triage is part of collective effort done by students of University of Rijeka Department of Informatics.]

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I am just clearing the needinfo. I haven't had an issue with this, though I am still using vga, so I probably wouldn't. At this point things have changed . enough, that if I run into the problem again I should just open a new bug, rather than reopen this one.