Bug reported by Cyrille Chépélov on the Debian BTS. Applies to 1.1.0 and git bc88513. He says: The radeonhd driver fails to properly enumerate available DVI connectors on my system and assign them proper resolutions. The video card is an integrated RS690 on an ASUS V2M motherboard. There is a VGA and a DVI connector. The DVI connector is connected to the DVI connector of the monitor through a single generic cable. The driver reports two DVI connectors, one able to run up to 1280x800 and connected to the monitor, the other able to run up to 1280x1024 (the actual native resolution of the monitor) RandR utilities see a similar report, grandr crashes when attempting to interact with the phantom second DVI connector. Once X starts with GPM, the card is initialized with a strange combination of 1280x800 and 1280x1024 resolutions: the X logical screen is 1280x800, while the monitor and physical display areas are initialized to 1280x1024. Pixels are reported square to applications. The mouse is free to roam all the way down to the 1024th line. Once the GNOME session starts, the top of the screen is replicated below the 800th line, and the mouse is free to roam on both parts. The GNOME-RandR applet shows only a few resolutions from 640x480 to 1024x800; selecting one actually changes the video mode to what's being shown in the RandR applet. PS: I do not have an available VGA cable around, and would like to avoid this extremity.
Please read http://wiki.x.org/wiki/radeonhd (Reporting Errors) and attach the necessary files.
Xorg.0.log and xorg.conf are obviously available at the Debian BTS URL given above, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;att=0;bug=462014 for the exact message containing them. If you need more, let me know, I'll ask the downstream reporter.
Having the logs in external sites is fine (for me at least), we just always need the URL. For most cases (here as well) we need Xorg.0.log with X run with -logverbose 7.
Created attachment 13961 [details] Xorg.0.log made with -logverbose 7
Created attachment 13962 [details] output of xdpyinfo as seen by radeonhd
Created attachment 13963 [details] output of xrandr --verbose, as seen by radeonhd
Created attachment 13964 [details] output of xrandr --verbose, as seen by fglrx 8.45.4
Additional points: The RS690 in question sits on a motherboard actually called M2A-VM, made by ASUS. The BIOS at the time of report was version "0601" (now deemed bad enough by Asus' QA to be out of download, unlike many prior and later versions), dated 2007-05-17. Furthermore, at the time of the report, ACPI was disabled (for independent reasons). The logs attached here have been made with a newer BIOS, after confirmation that the reported behaviour holds. The BIOS used is called version "1603", dated somewhere in october 2007. FWIW, the succint changelog is there: http://support.asus.com/download/download.aspx?SLanguage=en-us&model=M2A-VM%20HDMI&type=map&mapindex=1 FWIW too, this motherboard has a sibling, the M2A-VM-HDMI, which apparently differs by little than a riser that sits on the PCIe X16 (but which apparently is *not* a secondary display adapter), which provides a set of HDMI and SPDIF outputs. There are no obvious omitted components on this plain M2A-VM motherboard. The integrated BIOS upgrade utility refuses to take a BIOS made for the -HDMI variant on this riserless variant. However, the close relationship between the M2A-VM and M2A-VM-HDMI models might explain why there's the appearance of a second (phantom) DVI connector, in addition to the VGA? In any case, fglrx successfully sees that only the motherboard DVI is present and really active (or perhaps it would fail to recognise the riser, but that's quite doubtful) Thanks in advance
This looks very much like a duplicate of #14487. We don't deal correctly with the second ditial output (the ddia). That this is used has in fact not been discovered until very recently. I know pretty much what to do here - just need to find the time for it. *** This bug has been marked as a duplicate of bug 14487 ***
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.