http://bugs.freedesktop.org/show_bug.cgi?id=15989
--- Comment #11 from Egbert Eich
Created an attachment (id=18048) --> (http://bugs.freedesktop.org/attachment.cgi?id=18048) [details] Xorg.log file without a configuration, -logverbose 9
This is the new log file with -logverbose 9.
Thanks a lot! It was quite helpful.
Yes, I'm sure there's nothing connected to the HDMI connector, only to the DVI conector. Actually the other day I opened the case just to inspect it and look for anything suspicious and I couldn't spot anything.
I've got exactly the same board but the HDMI variant. It comes with an HDMI riser card that's plugged into the PEG slot (PCI-E 16x). Now your VBIOS the connector table shows this HDMI port although the HDMI riser card is not present. This would not be a problem, but according to the log that you've sent there is i2c data transaction on the DDC line that belongs to this non-existing HDMI port. On my system (with the riser card present) I get a NACK when I try to start an I2C transaction on this DDC line without any device detected. Apparently the checksum of the data that's transferred is incorrect according to the DDC specs so the Xserver doesn't try to interpret it as an EDID block. I wonder how this data looks like... rhd_conntest will help you to dump this data: ./rhd_conntest 1:5.0 -x 128 Presently with no hot plug information available we check for the presence of a device by trying to access the DDC line. If we receive an ACK on addressing the DDC slave address we assume a device is present. This heuristic seems to fail in your case which would be bad. It would mean that we'd have to transfer a full EDID blck and calculate the checksum to know if anything is connected. Here it would be good if RandR could be instructed to treat an output reading an existing but invalid EDID block as unconnected - especially for digital interfaces as for them the availability of EDID data is a requirement. But this would be more an randr less a driver issue.
Should I consider the possibility of a bad motherboard? Something else happens, namely every now and then the screen goes black for a second or two and then it resumes to normal. Initially I blamed the driver, but I've noticed that this happens with all the drivers that I've tried. Then I thought it could be the monitor, but I attached it to another machine and it seemed to work fine for a couple of hours (that's not conclusive, since the problem doesn't seem to have a pattern to it, sometimes hours go by before it happens and sometimes it happens several times in a row). I have noticed that it happens less often with this driver.
It could be that the electrical characteristics of the TMDS link to the monitor are slightly off. You could also try to switch to coherent mode. This is implemented as an output property. Please use xrandr --prop to check and xrandr --set <property> <value> change the state. Once I get face time with my machine again I will try to reproduce this by pulling out the HDMI riser card.
I used 3e2ee2f4722db20dcaf0d08f572b39541b8ec19f to test.
Something else: I'm running a amd64 distribution, if that's somehow relevant.
No, this is completely irrelevant here. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ xorg-team mailing list xorg-team@lists.x.org http://lists.x.org/mailman/listinfo/xorg-team -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org