Created attachment 17014 [details] xorg.conf I have an "early 2008" Mac Pro with an ATI Radeon HD 2600XT. I purchased the ATI card second hand, it's supposed to be an Apple Card, I believe the seller, and it works correctly in Mac OS but I didn't receive it directly from apple so I can't swear to its veracity.... I purchased the system with the Nvidia card and wanted to see if any of the ATI drivers gave me a better X experience. I'm using a Dell 3007WFP monitor. My system is running the amd64 FreeBSD's -STABLE release (FreeBSD 7) with xorg and gnome stuff built from the ports tree as of mid-May. I run X sessions using startx, which calls gnome-session. When I tried xf86-video-radeon-hd-1.2.1 from the ports tree I was faced with a black screen after starting X. On a whim I plugged the monitor into the #2 dvi connection and discovered my gnome desktop. When I exited my gnome session I was faced with a black screen and no console. Moving the video cable back to DVI #1 restores my console. I fetched the git version of the driver yesterday. The "./autogen.sh" step fails, complaining about a docs related macro that it doesn't know about. Subsequent make's fail in man. Since I didn't need the man pages I just cd'd into the src dir, did a mkae and then a make install. This splats the driver bits over the pre-existing freebsd port/package, but I think it get's the important parts in the right place. With the git version both the console (booting with the display connected to DVI #1) and my X session work, but randr -q reports that the monitor is on DVI-I_2. I'm attaching my xorg.conf, I don't see any way to add more than one attachment, so I'll come back and attach my Xorg.0.log and xrandr output.
Created attachment 17015 [details] xrandr output
Created attachment 17016 [details] Xorg.0.log
The README tells you how to get those macros. Are there any specific reasons why you didn't read the README, or is there a different place you did look at but didn't find the info?
(In reply to comment #3) > The README tells you how to get those macros. > > Are there any specific reasons why you didn't read the README, or is there a > different place you did look at but didn't find the info? > Actually, I *did* read the README. End to end. Several times. No, actually the README doesn't tell me how to get the macros I "need", for two reasons. First, the readme supposedly tells one what to do when you're missing XORG_DRIVER_CHECK_EXT. The error I was seeing was: configure.ac:288: error: possibly undefined macro: XORG_MANPAGE_SECTIONS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. And second, there are no ports available in the FreeBSD ports tree named xorg-dev, xorg-x11-server-sdk and xorg-x11-util-macros, nor did I find anything "similar" in any of the places I thought to look. This suggested to me that the README text was linux specific or distro specific. Since I built the entire FreeBSD release from source, the entire xorg distribution from source, and as part of that the version of radeonhd that was in the ports tree at the time from source, I was reasonably confident that I have all of the current-as-of-my-ports-tree development bits up to date. I was wrong though.... As it turns out, the FreeBSD specific hint (maybe it should be added to the README) is that that you need to install the devel/xorg-macros port/package. I didn't bother running it down at the time because I didn't care about the docs portion, but a bit more google work just now found it. I'm not entirely sure how I built the ports version of the xf86-video-radeon driver without it, but.... As you read through the bug you'll see that it is *NOT* a bug about not being able to build the git src. It's a report of funny mapping of connector information. I hope that the xorg.conf, xrandr output, and Xorg.0.log that I attached, as requested, will give you enough information to round out the tables that the driver uses to cope with honked up cards. I've pulled the card out for the moment, I get slightly better performance from the nascent open source nvidia driver on the Mac Pro nvidia board that I got with the ati board and its open source driver. If someone touches up the drivers configuration tables and wants me to give it a test, I'm happy to swap the hardware back in. Thanks for taking the time to look at this.
(In reply to comment #4) > (In reply to comment #3) > > The README tells you how to get those macros. > > > > Are there any specific reasons why you didn't read the README, or is there a > > different place you did look at but didn't find the info? > > > > Actually, I *did* read the README. End to end. Several times. OK, then I did something wrong. > No, actually the README doesn't tell me how to get the macros I "need", for two > reasons. First, the readme supposedly tells one what to do when you're missing > XORG_DRIVER_CHECK_EXT. The error I was seeing was: > > configure.ac:288: error: possibly undefined macro: XORG_MANPAGE_SECTIONS > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. I have submitted a patch explicitly mentioning the other macros for committing a few days ago, so this is covered. > And second, there are no ports available in the FreeBSD ports tree named > xorg-dev, xorg-x11-server-sdk and xorg-x11-util-macros, nor did I find anything > "similar" in any of the places I thought to look. Well, I'd have thought "devel/xorg-macros" was "similar". But, well.. > As it turns out, the FreeBSD specific hint (maybe it should be added to the > README) is that that you need to install the devel/xorg-macros port/package. Thanks, I'll add that. > As you read through the bug you'll see that it is *NOT* a bug about not being > able to build the git src. It's a report of funny mapping of connector > information. I hope that the xorg.conf, xrandr output, and Xorg.0.log that I > attached, as requested, will give you enough information to round out the > tables that the driver uses to cope with honked up cards. I'll leave that part to people who actually know the hardware :-) I'm only doing the housekeeping stuff.
(In reply to comment #0) George, thanks for the report! It at least showed that the driver in the latest git works on your card. > With the git version both the console (booting with the display connected to > DVI #1) and my X session work, but randr -q reports that the monitor is on > DVI-I_2. How do you do your enumeration (ie. what do you call DVI #1)? Is there anything printed on the rear panel or do you just go from top to bottom? According to the AtomBIOS connector table your monitor is connected to (II) RADEONHD(0): Connector[1] {RHD_CONNECTOR_DVI, "DUAL_LINK_DVI_I CRT1 DFP2", RHD_DDC_0, RHD_HPD_1, { RHD_OUTPUT_LVTMA, RHD_OUTPUT_DACA } } We just see the connector table. This table doesn't describe the location of the connectors in the back. This connector has both CRT1 and DFP2. So how should we order them? We have repeatedly asked ATI about how to map connector locations to connector table entries so that we would be able to reorder the entries however the answers we have gotten were inconclusive. Thus we just keep the order in which the entries are found in the connector tables which later on controls our enumeration. Once we understand this better we might be able to give locations (top, bottom) instead of numbers in the randr output. Until we understand this better you may just have to live with the fact that your DVI #1 is called DVI-I_2 in the randr output. Word of caution: Even if there is a general heursitics how to map connector table entries to real connectors some vendors may get this wrong. In this case a sceme that tried to provide the location may be even more confusing to the user. I don't think this is really a bug. For all the reasons stated above it might be hard to do any better. I would like to close this therefore.
(In reply to comment #6) > (In reply to comment #0) > > George, thanks for the report! It at least showed that the driver in the latest > git works on your card. > > > With the git version both the console (booting with the display connected to > > DVI #1) and my X session work, but randr -q reports that the monitor is on > > DVI-I_2. > > How do you do your enumeration (ie. what do you call DVI #1)? > Is there anything printed on the rear panel or do you just go from top to > bottom? > According to the AtomBIOS connector table your monitor is connected to > > (II) RADEONHD(0): Connector[1] {RHD_CONNECTOR_DVI, "DUAL_LINK_DVI_I CRT1 DFP2", > RHD_DDC_0, RHD_HPD_1, { RHD_OUTPUT_LVTMA, RHD_OUTPUT_DACA } } > I based it on the numbers printed next to the connectors on the card. It's not a huge deal, just thought I remembered seeing a comment/commit message that suggested that you were collecting quirks to deal with cards that didn't report the right data, and thought I'd contribute a bit of info. thanks for looking into it.
George, thanks! Yes we collect quirks but we do this mainly to override connector tables that are inconsistent in itself. Mostly this affects HPD pin assignment on R5xx chips. In this case the connector table itself seems to be correct but it's unclear how to match it to the numbers on the panel. In your case the numbering scheme seems to follow the CRTn (not the DFPn) numbering. If we had enough time and resources we could try to find out if this is generally (predominantly?!?) the case and adopt the naming sceme for connectors in randr accordingly.
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.