Alan:
I have a permedia/3dlabs board. 
The chip is identified as PM3040. 
I am running 16 bit 1152 x 870; 64k, 70 HZ as I type this. This is the highest 
I can get for resolution and reasonable color.
MicroSoft says that the video memory is:
000A0000 - 000AFFFF
000B0000 - 000BFFFF
000C0000 - 000A65FF
0E080000 - 0E08FFFF
E0000000 - E07FFFFF
E0800000 - E08FFFFF
E1000000 - E101FFFF

I have a Gateway EV700 monitor.

I configure with setup and select Xconfigurator where I select settings 
manually because probe does not work. I cannot get a working configuration. I 
think I have the same sort of problem noted above. I had a slackware Linux 5 on 
here that did work X. My Linux is marked "Seawolf Release". I bought an earlier 
copy of Red Hat that also did not work, so I never was able to register it. 
This copy is from "Cheap Bytes". I am sending this from Win98 2ed.

There may be a setup selection I can use, however I cannot find it. 

My e-mail is mwinthrop.com also winthrom (when I am at work)

Cheerfully!
Michael F. Winthrop

Reassigned to new X config tool component.

GMX2K multichip problem at least still exists. Can't currently test the other cases

*** Bug 56437 has been marked as a duplicate of this bug. ***

Alan, please try with the latest redhat-config-xfree86.  I've added some code
that should allow the tool to loop through all the available video cards in the
system until it finds one that it can start X on.  What I don't know is how it
will handle multichip video cards.  It depends on if kudzu return two separate
cards or just one.

If it doesn't work, try this:

1. 'python'
2. 'import kudzu'
3. 'cards = kudzu.probe(kudzu.CLASS_VIDEO, kudzu.BUS_PCI | kudzu.BUS_SBUS,
kudzu.PROBE_ALL)'
4. 'print cards'

What does 'cards' contain?

Cards contains

[Desc:           3DLabs|GLINT MX
Driver:         Card:ELSA GLoria-L/MX
Device:         None
, Desc:           3DLabs|GLINT MX
Driver:         Card:ELSA GLoria-L/MX
Device:         None
, Desc:           3DLabs|Permedia II 2D+3D
Driver:          Card:3Dlabs Permedia2 (generic)
Device:         None
]

All three of which are the wrong answer. The correct answer is

01:05.2 Display controller: 3DLabs GLINT MX (rev 01)
        Subsystem: 3DLabs: Unknown device 0106
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
        Memory at ef020000 (32-bit, non-prefetchable) [size=128K]
        Memory at ee800000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at eb000000 [disabled] [size=64K]

It looks like kudzu is not also searching for objects of class 'Display Controller'

I wonder if kudzu even knows how to probe "Display Controller" devices.  Let's
see if kudzu lists the card in a complete probe.

Try:

1. 'python'
2. 'import kudzu'
3. 'devices = kudzu.probe(kudzu.CLASS_UNSPEC, kudzu.BUS_UNSPEC,kudzu.PROBE_ALL)'
4. 'print devices'

If kudzu doesn't see the card at all, then maybe there is no entry for this card
in the pcitable from hwdata.

Device:         None
, Desc:           3DLabs|GLINT Gamma G1

So I see two problems.  One is the kudzu doesn't think that this is a video
card.  Two is that there's no driver listed for this device in pcitable:

0x3d3d  0x0008  "unknown"       "3DLabs|GLINT Gamma G1"

Both of these problems seem beyond the scope of redhat-config-xfree86, but I'm
not sure what to do next.

reassign it to kudzu ? 8)

Yeah, but that won't solve the lack of a driver problem.  Maybe a driver exists
but we just don't have the entry in hwdata.  mharris might know.

Reassigning to kudzu.

The driver is "glint"
The BusID field is also required

They arent common cards so its not a disaster

Brent / notting / whoever looks into this.

Multichip video cards can be detected by looking at the PCI bus ID of
the device.  Each chip will be a subfunction.  This hold true for all
of the above cards:

      Subfunction
      | 
      | 
      | 
00:0a.0 VGA compatible controller: Avance Logic Inc. ALG-2064i (prog-if 00
00:0a.1 Co-processor: 3DLabs GLINT Delta (rev 01)
00:0a.2 Display controller: 3DLabs GLINT 500TX (rev 01)
	Flags: bus master, medium devsel, latency 64, IRQ 12
	Memory at effc0000 (32-bit, non-prefetchable) [size=128K]
	Memory at ef000000 (32-bit, non-prefetchable) [size=8M]
	Memory at ee800000 (32-bit, non-prefetchable) [size=8M]
	Expansion ROM at effb0000 [disabled] [size=64K]

The above would be a Class 300 device with 3 subfunctions.


2. 3DLabs Oxygen GMX 2000

      Subfunction
      |
03:05.0 Co-processor: 3DLabs GLINT Gamma G1 (rev 01)
03:05.1 Display controller: 3DLabs GLINT MX (rev 01)
03:05.2 Display controller: 3DLabs GLINT MX (rev 01)
03:05.3 VGA compatible controller: 3DLabs Permedia II 2D+3D (rev 01) (prog-if 00

Subfunction 3 is the class 300 device here, so we'd want to scan all
subfunctions for a given device to see if we find a class 300 first, and
if so, then configure it, and any other subfunctions that there is
driver support for.

The 3Dlabs cards all seem to come in this complex configuration, however
there are some Nvidia cards like this as well, and the latest ATI hardware
also shows up as multiple devices.  We'll need a generalized infrastructure
for handling this I guess.

Its because its now easier to rip the vga crap out of the core video logic and
put a seperate pure vga controller in (for boot, windows setup, bios blah) with
a video signal switch than it is to keep all the PC legacy junk screwing up gate
counts in the high performance chunk.

Its likely to become very common indeed.

Ah, didn't know that.  Makes a lot of sense I guess.

Our tools should be able to handle this type of stuff for the future IMHO.

*** Bug 81232 has been marked as a duplicate of this bug. ***

(In reply to comment #14)
> Its because its now easier to rip the vga crap out of the core video logic and
> put a seperate pure vga controller in (for boot, windows setup, bios blah) with
> a video signal switch than it is to keep all the PC legacy junk screwing up gate
> counts in the high performance chunk.
> 
> Its likely to become very common indeed

2 years later now, and it appears all signs that no new video hardware coming
out is using this approach.  I would hypothesize that we'll never see new
hardware doing this in the future.

We've not had any bug reports from any other users in the same timeframe
for such multichip video hardware either, so I'd suspect the total number
of users affected by this problem is either quite small (insignificant),
or that the necessary bits are implemented in our config tools already,
and this bug just never got closed.

If we still don't handle this situation however, I'd suspect it would be
sufficiently low priority on the development radar that we'd probably
not spend resources implementing such functionality unless it was required
by new high end hardware coming out, and we were to receive a MustFix
feature enhancement request from an IHV such as Dell/HP/IBM or similar.

Either way, I think it's probably safe to close this bug "WONTFIX" or
"CURRENTRELEASE" now.

Reassigning to system-config-display component for review.

It seems to have proven cheaper to stick both on one chip in the end. No current
card I know of kept the split so we can close it.