Bug 108963 - ATI FireGL X1 does not work with second monitor in dual-head config
ATI FireGL X1 does not work with second monitor in dual-head config
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-03 15:39 EST by Dan Williams
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-07 21:55:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XFree log from last login (43.94 KB, text/plain)
2003-11-03 15:40 EST, Dan Williams
no flags Details
Correct XF86 log with Screen 0 in videocard0 Device section (43.94 KB, text/plain)
2003-11-03 15:45 EST, Dan Williams
no flags Details
XF86 Config (3.73 KB, text/plain)
2003-11-03 15:47 EST, Dan Williams
no flags Details
/var/log/messages (60.53 KB, text/plain)
2003-11-03 15:47 EST, Dan Williams
no flags Details
XF86Config (2.33 KB, text/plain)
2003-11-18 18:54 EST, Michael J. Carter
no flags Details
XFree86.0.log (43.21 KB, text/plain)
2003-11-18 18:57 EST, Michael J. Carter
no flags Details
X log using merged FB option (51.20 KB, text/plain)
2003-11-21 17:21 EST, Mark Heslep
no flags Details
config using mergedFB from DRI (3.00 KB, text/plain)
2003-11-21 17:31 EST, Mark Heslep
no flags Details

  None (edit)
Description Dan Williams 2003-11-03 15:39:22 EST
Version-Release number of selected component (if applicable):
Fedora Core 1 (Yarrow)
XFree86 4.3.0-42

Card is an ATI FireGL X1, with 2 DVI outputs.  For one montior it
works just fine.  Connecting 2 monitors, one to each DVI output
through a DVI->VGA adaptor results in:

1) Second monitor never locks onto signal from card
2) First monitor works as expected

I initially had no Screen 1 or Screen 0 in the Devices section in the
XF86Config file, and without these the main monitor was stuck at
640x480 and never more, no matter what was in XF86Config.  Adding
Screen 1 and Screen 0 to those sections allows the first monitor to
work correctly.

Monitors:  HP P1100 (main), Dell M990 (secondary)
Comment 1 Dan Williams 2003-11-03 15:40:00 EST
Created attachment 95688 [details]
XFree log from last login
Comment 2 Dan Williams 2003-11-03 15:45:55 EST
Created attachment 95689 [details]
Correct XF86 log with Screen 0 in videocard0 Device section
Comment 3 Dan Williams 2003-11-03 15:47:00 EST
Created attachment 95690 [details]
XF86 Config
Comment 4 Dan Williams 2003-11-03 15:47:46 EST
Created attachment 95691 [details]
/var/log/messages
Comment 5 John Dennis 2003-11-03 17:15:56 EST
O.K. here is what I know after a quick investigation.

The FireGL X1 shows up on the pci bus as two devices at bus addresses
1.0.0 and 1.0.1, each as a unique PCI device id 0x4E47 and 0x4E67
respectively. 0x4E67 is the second head, it has its own framebuffer
and registers independent from the first head (e.g. its PCI BAR
registers are unique). The 0x4E47 ID is in the list RADEONChipsets in
radeon_probe.c:

    { PCI_CHIP_R300_NG, "ATI FireGL X1 NG (AGP)" },

however the second head as PCI ID 0x4E67 is not in the list. Thus when
xf86MatchPciInstances is invoked by RADEONprobe it fails to locate the
second head, this mean all pci instances point to the first head. When
RADEONPreInitConfig is called for the second screen its entity
instance is pointing to the first head and as a consequence it uses
the framebuffer and register set for the first head.

Dual head is handled differently in many instances, but this
preliminary investigation suggests we might want to try adding the PCI
ID for the second head so the driver will recognize it and try to
initialize it. It seems a very obvious fix (if thats the answer), it
might be worthwhile to check the head of the XFree86 CVS tree and see
if its there.

John

Comment 6 John Dennis 2003-11-03 17:28:20 EST
The current XFree86 CVS tree does not have the 0x4E67 PCI ID, without
this I doubt the second head will initialize correctly.
Comment 7 Mark Heslep 2003-11-07 18:07:10 EST
Im seeing the same a similar problem w/ the FireGL X1 though X totally
hung on my graphical FC 1 install w/ both NEC 1860 LCD panels
attached. Text install worked fine.   Same thing happens after the
install when trying to start X.  Unplug the second panel though and X
starts / operates fine. 

Comment 8 Alex Deucher 2003-11-17 18:36:12 EST
the second pci id is just a flag for the windows drivers.  dualhead is
all handled by the driver on the primary id.  the problem is that
there is only one integrated tmds controller so the second dvi port is
controlled by an external tmds chip.  I suspect the current radeon
driver does not yet have support for that secondary chip yet.  You
might want to inquire with ATI.  ALso if you are using xfree86 cvs, try:
Option "monitorlayout" "tdms, tdms"
in the device section of your config file.  Also make sure you sepcify
the bus id (	BusID       "PCI:1:0:0") in both device sections.
Comment 9 Alex Deucher 2003-11-17 18:41:17 EST
whoops, I didn't realize you were using dvi->vga adapters... try:
Option "monitorlayout" "crt, crt"
instead.
Comment 10 Dan Williams 2003-11-18 15:14:29 EST
You mention XF86 CVS, does this only work using a recent checkout?  I
can't get it to work with XFree86-4.3.0-42 RPMs.
Comment 11 Mike A. Harris 2003-11-18 15:24:50 EST
>might want to inquire with ATI.  ALso if you are using xfree86 cvs,
>try: Option "monitorlayout" "tdms, tdms"

Just a note for anyone reading the above, there is a slight typo:

s/tdms/tmds/
Comment 12 Mike A. Harris 2003-11-18 15:29:03 EST
Can anyone reproduce this on RHEL3?  I presume the answer is yes,
as that is what would be expected.  I'd like to install RHEL3 on
my ia64 with the X1 in it to test this, but wondered if someone
else might have tested RHEL 3 out already on X1.

I only have 2 machines the X1 will plug into (AGP Pro), and the
ia64 is the only one I'm likely to be able to test on anytime soon
as the other machine is my main workstation.

I believe agd5f@yahoo.com's suggestion of using monitorlayout might
solve this problem.  If someone could please test that and provide
feedback, that would be helpful for our investigation.

TIA
Comment 13 John Dennis 2003-11-18 15:34:47 EST
Mike, I have tested this with XFree86-4.3.0-16.EL on ia64. We also
just tried the suggestions from Allen (agd5f) but it was not
successful. I do have a "hacked" radeon driver that recognizes the new
pci id and it does go all the way through the process of init'ing both
heads, but no video output. We have not tried the Allen's extra config
option on this driver yet though.
Comment 14 Mike A. Harris 2003-11-18 15:46:13 EST
4.3.0-16 is probably way too old...  I added newer hardware support
sometime in the 4.3.0-3[0-9] series IIRC.  XFree86-4.3.0-35.EL is what
shipped in RHEL 3 IIRC, and it is missing some of the Radeon bits that
are in Fedora Core, although a future update will sync them again.

It'd be useful to test with a gold master release for RHEL3 in case
there is a difference, although I suspect RHEL3 and Fedora will be the
same.
Comment 15 Mark Heslep 2003-11-18 18:06:02 EST
Adding the MonitorLayout option as a work around might work post
install but it still leaves us stuck w/ the FC 1 install failure. 
Again - graphical install totally hangs on this card if the 2nd head
is plugged in (DVI / VGA adapter).  To fix that, then, what? Roll the
fix into the installation images?  Is that TinyX in there or something
similar.
Comment 16 Michael J. Carter 2003-11-18 18:54:46 EST
Created attachment 96050 [details]
XF86Config
Comment 17 Michael J. Carter 2003-11-18 18:56:14 EST
Just confirming that I'm seeing the same problem on RHEL3WS i386:

[root@voldemort root]# rpm -q XFree86
XFree86-4.3.0-35.EL

I think I have the MonitorLayout option correct.

XF86Config and XF86Confog.0.log attached
Comment 18 Michael J. Carter 2003-11-18 18:57:10 EST
Created attachment 96051 [details]
XFree86.0.log
Comment 19 Mark Heslep 2003-11-21 17:21:36 EST
Created attachment 96132 [details]
X log using merged FB option
Comment 20 Mark Heslep 2003-11-21 17:29:24 EST
OK for comparison the DRI from freedesktop.org CVS does not have the
2nd head problem.  Dual head works fine with both the MergedFB option
off and with it on.  Feels like about two miles of blue Fedora 'Flower
petals' in front of me.  Attached log and config using  MergedFB.

BTW, w/ dual head working (and only w/ dual head) the logout process
locks up the desktop and  you must resort to CTL-ALT-BKSPACE to return
to the console. But, I suppose that should be a different bug, filed
under _____?

Comment 21 Mark Heslep 2003-11-21 17:31:34 EST
Created attachment 96133 [details]
config using mergedFB from DRI
Comment 22 Mark Heslep 2003-11-21 17:34:24 EST
DRI CVS I used is here:
http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/xc.tar.gz?tarball=1&cvsroot=dri

The traditional dri.sourceforge.net is stale.
Comment 23 Mike A. Harris 2004-03-04 22:33:39 EST
The DRI CVS repository located on sourceforge is obsolete and
abandoned.  DRI CVS officially moved to freedesktop.org some months
back.  It might be a good idea for us to request that they remove
the old repository to avoid confusion though. Thanks for bringing
this to my attention.

Comment 24 Mike A. Harris 2005-02-07 21:55:43 EST
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:

        http://fedora.redhat.com/download

If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Setting status to "CURRENTRELEASE".

Note You need to log in before you can comment on or make changes to this bug.