Created attachment 16600 [details] Xorg.log file without a configuration file If I configure the radeon driver to use RandR, some applications like GDM and the GNOME panel don't occupy the full screen but a fraction of it. Looking at the log file I see: (II) RADEONHD(0): Output VGA_1 disconnected (II) RADEONHD(0): Output TV_SVIDEO disconnected (II) RADEONHD(0): Output DVI-D_1 connected (II) RADEONHD(0): Output DVI-D_2 connected (II) RADEONHD(0): Output DVI-D_1 using initial mode 1280x800 (II) RADEONHD(0): Output DVI-D_2 using initial mode 1680x1050 It's a RS690 as the log says. It's integrated in the motherboard. Physically the motherboard has two display connectors, one VGA, one DVI. The monitor is connected to the DVI output. The monitor resolution, as seen in the log file is 1680x1050. Problem: GDM behaves as if the display resolution was set to 1280x800. Furthermore, the output of xdpyinfo says the display resolution is in fact 1680x1050, but xrandr reports only up to 1280x800. Initially the GNOME panels are only 1280 pixels wide and the lower one is located at the "edge" of the 800 pixel tall display, but I can drag it to the lower edge of the monitor and it will expand to occupy the full 1680 pixels. If I disable RandR using the NoRandR option, everything behaves ok. Is this a problem in the radeonhd driver or a problem in GNOME? The problem is easy to reproduce for me, I can provide more information on request.
Created attachment 16601 [details] Xorg.log with provided configuration file This is the log file matching the configuration file used to disable RandR.
Created attachment 16602 [details] Configuration file used to disable RandR
Hey Marcello, you're still alive? :-))) Long time no see... It seems you're hitting a combination of two bugs. One is the issue (I would call it a bug) that gnome always takes the resolution of the first Xinerama screen (actually the emulation of Xinerama done by RandR) as the "primary" screen - and RandR doesn't impose any ordering on the outputs as received by the driver. I added the option "RROutputOrder" for this type of bug, by which you can prefer DVI-D_2, and the order of the Xinerama screens will change. The other issue is that the connector table seems to be strange - two DVI-D connectors? Does this laptop have a docking station connector? Also, both connectors seem to be connected (even more weired) - one being LVTMA, one being DVO. Egbert should know whether those two somehow conflict, in that case we need additional logic.
There is no HPD info in the connector table (although the LVTMA has an HPD assigned). One could generate a connector table but as this problem seems to be consistent across all RS690 systems it is hard to fix for all. I've checked how else we can work around this issue - unfortunately i have no idea. Marcelo, do you really have two monitors connected? I don't see any DDC output from the one connected to DVI-D_1. In this case this connector should have the state disconnected. I've got the same board so I will check where this comes from.
I've just tested this: with just one monitor connected to the DVI-D or the HDMI connector the system behaves correctly and detects only one output as connected. With both monitors attached I get the described behavior but I get two EDID blocks. I wonder where the 1200x800 mode comes from that is used for the primary output. Marcelo, could you please provide a -logverbose 7 output? It would help to shed some light onto the problem. (assigning to the reporter for feedback - Marcelo, please assign back to me when done, thanks.
Created attachment 16659 [details] X log with -logverbose 7, no configuration file
Hi Matthias! Long time no see. Thanks for the hint, I had tried that but I used the wrong parameter. I tried again with DVI-D_2 and it worked! This is not a laptop, it's a desktop. The motherboard (Asus M2A-VM) has one VGA output and one DVI output. I'm not sure where the other DVI output is coming from. Perhaps an internal connector that wasn't really enabled in this motherboard? Egbert, there's only one monitor connected, that's why there's only one DDC output. I attached the log file with -logverbose 7. Thanks!
Looking at the log file more closely it seems that the DVI-1 (the DDIA block on the HDMI connector) block detects an output (thru DDC) which however doesn't provide DDC data. (II) RADEONHD(0): rhdRROutputDetect: Output DVI-D_1 (II) RADEONHD(0): FUNCTION: rhdRS69WriteRead (II) RADEONHD(0): FUNCTION: rhdRS69I2CSetupStatus (II) RADEONHD(0): FUNCTION: RHDAtomBiosFunc (II) RADEONHD(0): FUNCTION: rhdAtomGPIOI2CInfoQuery (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f90 (II) RADEONHD(0): rhdRS69I2CSetupStatus: DDC Line: 2 val: 0 port: 0x1f90 (II) RADEONHD(0): FUNCTION: rhdRS69I2CStatus (II) RADEONHD(0): rhdRROutputGetModes: Output DVI-D_1 Since there is no DDC data for this output some low ranges are assumed which contain the 1280x800 mode. So the driver drives the HDMI output with 1280x800 although nothing is there and the mode that the gnome desktop sees is exactly this mode. Marcelo: Are you sure there is nothing connected to the HDMI port? I've tried to reproduce this with exactly the same board here however I don't see this issue. Could you refetch the latest driver (the version I've just pushed) and regenerate a verbose log file (this time -logverbose 8 !!!). Please use the same setup as you have used before: an LCD connected to the DVI port, nothing connected to HDMI.
Created attachment 18048 [details] Xorg.log file without a configuration, -logverbose 9 This is the new log file with -logverbose 9. 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. 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. I used 3e2ee2f4722db20dcaf0d08f572b39541b8ec19f to test. Something else: I'm running a amd64 distribution, if that's somehow relevant.
Sorry, I meant there's nothing attached to the VGA connector. This board does not have a HDMI connector.
(In reply to comment #9) > Created an attachment (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.
rhd_conntest: v1.2.1, git branch master, commit 3e2ee2f4 + changes Checking connectors on 0x791E, 0x1043, 0x826D (@01:05:00): Load Detection: RHD_OUTPUT_NONE HotPlug: RHD_HPD_0 DDC: RHD_DDC_1 RHD_DDC_2 LVDS Info: 18bits, single link, LDI Panel found. Power Timing: 0x000, 0x000, 0x00, 0x00, 0x000 Macro: 0x00000000, Clock Pattern: 0x0001 Thanks for the tip about the other issue, I'll try that!
OK, i've pulled the HDMI riser board from my system and it started to exhibit the same behavior: *all* I2C slave addresses on DDC2 start responding. When reading one gets all zeros. I then went ahead and disabled HDMI support in the BIOS with the hope that this would modify the connector table in the Video BIOS (like on a Gigabyte RS780 board). But this didn't happen. I didn't see any effect when doing this. I guess one could modify the DDC Probe to read the first to bytes of an EDID block and check that they are 0x00 0xff. This is really a hardware brokenness. I wonder if a BIOS update would make a difference here.
I did a BIOS upgrade to revision 1901. That seems to have taken care of the "going black" issue, but both DVI-D_1 and DVI-D_2 are still reported as being connected. I haven't tried disabling HDMI to see if this changes anything with this new BIOS release. Thanks!
Marcelo, I've made a patch for the driver which should address this issue. This 'improved' detection code should be able to handle slightly broken hardware - like this ASUS board. commit 20f3df0900f7a03ef9b56710590a4523fa1c74ed should take care of this. I've tested it here with my board and it seems to work.
On Mon, Aug 4, 2008 at 5:49 AM, <bugzilla-daemon@freedesktop.org> wrote: > Marcelo, I've made a patch for the driver which should address this > issue. This 'improved' detection code should be able to handle > slightly broken hardware - like this ASUS board. commit > 20f3df0900f7a03ef9b56710590a4523fa1c74ed should take care of this. > I've tested it here with my board and it seems to work. Yes, I can confirm it works great on my end, too :-) Thanks a lot! Marcelo
OK, so let's mark this fixed.
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.