Bug 58532 - r-c-xfree has problems with multichip video cards
r-c-xfree has problems with multichip video cards
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: system-config-display (Show other bugs)
rawhide
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Søren Sandmann Pedersen
:
: 56437 81232 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-18 16:48 EST by Alan Cox
Modified: 2014-06-18 05:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-03 03:56:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alan Cox 2002-01-18 16:48:39 EST
Two samples enclosed that hopefully help for fixing this

1.  Accelegraphics 3D Labs delta/500tx board
     (XFree86 mistakenly takes the VGA controller which is just a 1Mb card
      for compat mode stuff)

00:0a.0 VGA compatible controller: Avance Logic Inc. ALG-2064i (prog-if 00 [VGA])
	Flags: medium devsel, IRQ 12
	Memory at efc00000 (32-bit, non-prefetchable) [disabled] [size=2M]
	Expansion ROM at effa0000 [disabled] [size=32K]

00:0a.1 Co-processor: 3DLabs GLINT Delta (rev 01)
	Flags: bus master, medium devsel, latency 64, IRQ 12
	Memory at eff80000 (32-bit, non-prefetchable) [size=128K]

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]

2. 3DLabs Oxygen GMX 2000


03:05.0 Co-processor: 3DLabs GLINT Gamma G1 (rev 01)
	Subsystem: 3DLabs: Unknown device 0106
	Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
	Memory at ed940000 (32-bit, non-prefetchable) [size=128K]
	Memory at e8000000 (32-bit, non-prefetchable) [size=32M]
	Capabilities: <available only to root>

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

03: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 ed9a0000 (32-bit, non-prefetchable) [size=128K]
	Memory at ec000000 (32-bit, non-prefetchable) [size=8M]
	Expansion ROM at ed9c0000 [disabled] [size=64K]

03:05.3 VGA compatible controller: 3DLabs Permedia II 2D+3D (rev 01) (prog-if 00
[VGA])
	Subsystem: 3DLabs: Unknown device 0106
	Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
	Memory at ed9e0000 (32-bit, non-prefetchable) [size=128K]
	Memory at ed000000 (32-bit, non-prefetchable) [size=8M]
	Memory at ec800000 (32-bit, non-prefetchable) [size=8M]
	Expansion ROM at ed9d0000 [disabled] [size=64K]
	Capabilities: <available only to root>

(Mistakenly identified as a Permedia II - again only there for back compat)
Comment 1 Michael F. Winthrop 2002-01-19 01:41:16 EST
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@cox.rr.com also winthrom@hotmail.co (when I am at work)

Cheerfully!
Michael F. Winthrop
Comment 2 Mike A. Harris 2002-07-29 20:37:56 EDT
Reassigned to new X config tool component.
Comment 3 Alan Cox 2002-09-02 17:10:03 EDT
GMX2K multichip problem at least still exists. Can't currently test the other cases
Comment 4 Alexander Larsson 2002-10-02 03:18:56 EDT
*** Bug 56437 has been marked as a duplicate of this bug. ***
Comment 5 Brent Fox 2003-02-08 09:21:31 EST
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?
Comment 6 Alan Cox 2003-02-08 10:03:47 EST
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'
Comment 7 Brent Fox 2003-02-08 10:45:03 EST
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.
Comment 8 Alan Cox 2003-02-08 10:58:31 EST
Device:         None
, Desc:           3DLabs|GLINT Gamma G1
Comment 9 Brent Fox 2003-02-08 11:37:17 EST
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.
Comment 10 Alan Cox 2003-02-08 11:41:02 EST
reassign it to kudzu ? 8)
Comment 11 Brent Fox 2003-02-08 12:23:46 EST
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.
Comment 12 Alan Cox 2003-02-08 13:15:19 EST
The driver is "glint"
The BusID field is also required

They arent common cards so its not a disaster
Comment 13 Mike A. Harris 2003-02-08 18:03:45 EST
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.

Comment 14 Alan Cox 2003-02-08 18:32:28 EST
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.
Comment 15 Mike A. Harris 2003-02-08 19:09:59 EST
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.
Comment 16 Alan Cox 2003-08-14 06:13:32 EDT
*** Bug 81232 has been marked as a duplicate of this bug. ***
Comment 17 Mike A. Harris 2005-09-30 18:18:29 EDT
(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.
Comment 18 Alan Cox 2005-10-03 03:56:13 EDT
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.

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