Mixing g400 dualhead and old Millennium.

Mixing g400 dualhead and old Millennium.

[Carlo E. Prelz]

Hello. I am trying to obtain a 'simple' system where 3 framebuffers
output their images to three monitors (no TV output). In the past I
was able to have 4 outputs using 4 old millenniums. Now I have to help
a friend who lives 1000 kms from here, and who hasn't enough PCI slots
(and would not find 3 millenniums anyway...) So, he found a dualhead
AGP g400 (PCI ID 102b:0525) and an old Millennium (PCI ID 102b:0519,
MGA 2064W).

Using kernel 2.4.19, and loading kernel modules in this order:

i2c-matroxfb
matroxfb_base
matroxfb_crtc2

I see the cards as follows:

PCI: Found IRQ 9 for device 00:0b.0
matroxfb: Matrox Millennium (PCI) detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x6553)
matroxfb: framebuffer at 0xEB000000, mapped to 0xce875000, size 4194304
Console: switching to colour frame buffer device 80x30
fb0: MATROX VGA frame buffer device
PCI: Enabling device 01:00.0 (0000 -> 0002)
matroxfb: Matrox G400 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x26208)
matroxfb: framebuffer at 0xE8000000, mapped to 0xcf07b000, size 33554432
fb1: MATROX VGA frame buffer device
fb1: initializing hardware
i2c-core.o: adapter DDC:fb1 #0 on i2c-matroxfb registered as adapter 0.
i2c-core.o: adapter DDC:fb1 #1 on i2c-matroxfb registered as adapter 1.
i2c-core.o: adapter MAVEN:fb1 on i2c-matroxfb registered as adapter 2.
i2c-core.o: adapter DDC:fb0 #0 on i2c-matroxfb registered as adapter 3.
matroxfb_crtc2: secondary head of fb1 was registered as fb2

And I see the fb's: /proc/fb contains

0 MATROX VGA
1 MATROX VGA
2 MATROX CRTC2

The console is on the Millennium. The problem is that writing to
/dev/fb2 does not result in something appearing on the 2nd output of
the G400. Now, I must admit that my mind is not a little confused with
the usage and capacites of the matroxset utility, but here at home, I
was able to cleanly use the second output of my G450 with the
following code (run at boot time):

/usr/src/matroxset/matroxset -f /dev/fb1 -m 0
/usr/src/matroxset/matroxset -f /dev/fb0 -m 1
/usr/src/matroxset/matroxset -f /dev/fb1 -m 2

So, I tried the same on this remote machine (using /dev/fb1 and
/dev/fb2, of course). The third command is not successful. I explored
things a bit. I wrote a short program that calls 3 ioctls,
respectively 

MATROXFB_GET_OUTPUT_CONNECTION,
MATROXFB_GET_AVAILABLE_OUTPUTS and
MATROXFB_GET_ALL_OUTPUTS.

On my home machine, /dev/fb0 gives 1, 1 and 3, while /dev/fb1 gives 2,
2 and 3. I understand that these are bitmaps: all is good. On the
remote machine,

fb0 (millennium) gives 1, 1 and 1 (ok, only one output)
fb1 (g400 1st head) gives 1, 5 and 5
fb2 (g400 2nd head) gives 0, 0 and 5

So, it seems that the second bit is not available in the g400. In its
place, there seems to be a third bit, what in matroxfb.h is defined as
MATROXFB_OUTPUT_DFP; this, as far as I can see, relates to a digital
flat panel interface, some possible third output on the card (that I
cannot investigate since the card is far far away).

In all cases, it appears (when looking at the source of the driver)
that the second head cannot be assigned this value, so that
MATROXFB_GET_AVAILABLE_OUTPUTS is 0 for it. I can assign it to the
first head, as follows

/usr/src/matroxset/matroxset -f /dev/fb2 -m 0
/usr/src/matroxset/matroxset -f /dev/fb1 -m 4

but after that, too, MATROXFB_GET_AVAILABLE_OUTPUTS for the second
head is 0. Or I can assign 1 to the second head, but then I cannot
assign 4 to the first head, although it is allowed in
MATROXFB_GET_AVAILABLE_OUTPUTS, because I can only assign a value to
the primary head if the secondary head has no output assigned. 

I thought I may solve the problem by having the g400 card detected as
first and the Millennium as second, but this seems to be impossible,
since AGP is detected after PCI. 

Is this a bug? What can I do about it?

Thanks in advance...

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Mixing g400 dualhead and old Millennium.

[Petr Vandrovec]

On Sat, Oct 12, 2002 at 05:36:41PM +0200, Carlo E. Prelz wrote:
> Hello. I am trying to obtain a 'simple' system where 3 framebuffers
> output their images to three monitors (no TV output). In the past I
> was able to have 4 outputs using 4 old millenniums. Now I have to help
> a friend who lives 1000 kms from here, and who hasn't enough PCI slots
> (and would not find 3 millenniums anyway...) So, he found a dualhead
> AGP g400 (PCI ID 102b:0525) and an old Millennium (PCI ID 102b:0519,
> MGA 2064W).
> 
> Using kernel 2.4.19, and loading kernel modules in this order:
> 
> i2c-matroxfb
> matroxfb_base
> matroxfb_crtc2

If it is G400, you must also insmod matroxfb_maven, otherwise
there is no second output. And you should build everything
into kernel, not as a modules - you'll not have problem to find
where secondary output lives then...
 
> In all cases, it appears (when looking at the source of the driver)
> that the second head cannot be assigned this value, so that
> MATROXFB_GET_AVAILABLE_OUTPUTS is 0 for it. I can assign it to the
> first head, as follows
> 
> /usr/src/matroxset/matroxset -f /dev/fb2 -m 0
> /usr/src/matroxset/matroxset -f /dev/fb1 -m 4
> 
> but after that, too, MATROXFB_GET_AVAILABLE_OUTPUTS for the second
> head is 0. Or I can assign 1 to the second head, but then I cannot
> assign 4 to the first head, although it is allowed in
> MATROXFB_GET_AVAILABLE_OUTPUTS, because I can only assign a value to

Digital output and secondary output use same pins on G400, so you have
either one or another. On G450/G550 all three outputs are completely
independent, with proper cabling you can connect three monitors
to your Gx50 (of course, two of them will have same picture, but
it is enough if you are doing some presentations).
							Petr Vandrovec
					


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Mixing g400 dualhead and old Millennium.

[Carlo E. Prelz]

	Subject: Re: Mixing g400 dualhead and old Millennium.
	Date: dom, ott 13, 2002 at 02:13:24 +0200

Quoting Petr Vandrovec (vandrove@vc.cvut.cz):

> If it is G400, you must also insmod matroxfb_maven, otherwise
> there is no second output. 

Aha. That made the second output magically appear. Thanks!

> And you should build everything
> into kernel, not as a modules - you'll not have problem to find
> where secondary output lives then...

I was having problems in compiling things in kernel. Eventually, it
seems they were limited to compiling the latest 2.4.20-pre10-ac2
patch, which contains a more recent version of your material. With
that, both with modules and included in the kernel, I get the
following messages (here with modules);

PCI: Found IRQ 9 for device 00:0b.0
matroxfb: Matrox Millennium (PCI) detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x6553)
matroxfb: framebuffer at 0xEB000000, mapped to 0xce8d0000, size 4194304
Console: switching to colour frame buffer device 80x30
fb0: MATROX VGA frame buffer device
PCI: Enabling device 01:00.0 (0000 -> 0002)
matroxfb: Matrox G400 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x3270)
matroxfb: framebuffer at 0xE8000000, mapped to 0xcf0d6000, size 2097152
fb1: MATROX VGA frame buffer device
fb1: initializing hardware
i2c-core.o: adapter DDC:fb1 #0 on i2c-matroxfb registered as adapter 0.
i2c-core.o: adapter DDC:fb1 #1 on i2c-matroxfb registered as adapter 1.
i2c-core.o: adapter MAVEN:fb1 on i2c-matroxfb registered as adapter 2.
i2c-core.o: adapter DDC:fb0 #0 on i2c-matroxfb registered as adapter 3.
i2c-core.o: driver maven registered.
i2c-core.o: client [maven client] registered to adapter [MAVEN:fb1 on i2c-matroxfb](pos. 0).
matroxfb_crtc2: secondary head failed to register
matroxfb_crtc2: CRTC2 framebuffer failed to register

so that I cannot see the second head of the g400. With 2.4.19 and
module loading, instead of the last two lines I get:

matroxfb_crtc2: secondary head of fb1 was registered as fb2

This is not urgent for me now. I still cannot see if the output is
present on all outputs (somebody will have to physically check the
monitor outputs, and that will hopefully happen sometimes tomorrow),
but now the matroxset output looks very promising. 

In all cases, if you want me to do some tests or try some patch to see
if the 'failed to register' situation can be fixed, just ask.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Mixing g400 dualhead and old Millennium.

[Petr Vandrovec]

On Sun, Oct 13, 2002 at 04:15:16PM +0200, Carlo E. Prelz wrote:
> 
> I was having problems in compiling things in kernel. Eventually, it
> seems they were limited to compiling the latest 2.4.20-pre10-ac2
> patch, which contains a more recent version of your material. With
> that, both with modules and included in the kernel, I get the
> following messages (here with modules);

Strange, I'll have to look at 2.4.20-pre10-ac2 then. I do not
remember sending anything special for 2.4.20 to Alan...

> matroxfb_crtc2: secondary head failed to register
> matroxfb_crtc2: CRTC2 framebuffer failed to register

It can only happen if there is not enough memory (uh...) or if
register_framebuffer() fails. And only way I can imagine is
that you run out of possible framebuffers... Can you
verify that /usr/src/linux/include/linux/fb.h contains
'#define FB_MAX 32' and not some small value like '2' ?

> so that I cannot see the second head of the g400. With 2.4.19 and
> module loading, instead of the last two lines I get:
> 
> matroxfb_crtc2: secondary head of fb1 was registered as fb2
> 
> This is not urgent for me now. I still cannot see if the output is
> present on all outputs (somebody will have to physically check the
> monitor outputs, and that will hopefully happen sometimes tomorrow),
> but now the matroxset output looks very promising. 
> 
> In all cases, if you want me to do some tests or try some patch to see
> if the 'failed to register' situation can be fixed, just ask.

If you could print return value from register_framebuffer in 
matroxfb_dh_regit in matroxfb_crtc2.c, maybe it could reveal
problem. Maybe that using non-ac kernel fixes problem too.
						Petr Vandrovec
						vandrove@vc.cvut.cz


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Mixing g400 dualhead and old Millennium.

[Carlo E. Prelz]

	Subject: Re: Mixing g400 dualhead and old Millennium.
	Date: dom, ott 13, 2002 at 04:56:04 +0200

Quoting Petr Vandrovec (vandrove@vc.cvut.cz):

> Strange, I'll have to look at 2.4.20-pre10-ac2 then. I do not
> remember sending anything special for 2.4.20 to Alan...

Pre10-ac2 has a matroxfb_base.c with Version: 1.64 2002/06/10. Simple
pre10 has Version: 1.62 2001/11/29.

> > matroxfb_crtc2: secondary head failed to register
> > matroxfb_crtc2: CRTC2 framebuffer failed to register
> 
> It can only happen if there is not enough memory (uh...) or if
> register_framebuffer() fails. And only way I can imagine is
> that you run out of possible framebuffers... Can you
> verify that /usr/src/linux/include/linux/fb.h contains
> '#define FB_MAX 32' and not some small value like '2' ?

Both versions have 32. 

> If you could print return value from register_framebuffer in 
> matroxfb_dh_regit in matroxfb_crtc2.c, maybe it could reveal
> problem. Maybe that using non-ac kernel fixes problem too.

I will add a printk & will let you know.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Mixing g400 dualhead and old Millennium.

[Carlo E. Prelz]

	Subject: Re: Mixing g400 dualhead and old Millennium.
	Date: dom, ott 13, 2002 at 04:56:04 +0200

Quoting Petr Vandrovec (vandrove@vc.cvut.cz):

> If you could print return value from register_framebuffer in 
> matroxfb_dh_regit in matroxfb_crtc2.c, maybe it could reveal
> problem. Maybe that using non-ac kernel fixes problem too.

It never reaches register_framebuffer. It leaves dh_regit at tese
lines:

        else if (ACCESS_FBINFO(video.len) < mem) {
                kfree(d);
                return -ENOMEM;
        }

ACCESS_FBINFO(video.len) is 2097152. Mem is 8388608.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Mixing g400 dualhead and old Millennium.

[Petr Vandrovec]

On Sun, Oct 13, 2002 at 06:07:46PM +0200, Carlo E. Prelz wrote:
> 	Subject: Re: Mixing g400 dualhead and old Millennium.
> 	Date: dom, ott 13, 2002 at 04:56:04 +0200
> 
> Quoting Petr Vandrovec (vandrove@vc.cvut.cz):
> 
> > If you could print return value from register_framebuffer in 
> > matroxfb_dh_regit in matroxfb_crtc2.c, maybe it could reveal
> > problem. Maybe that using non-ac kernel fixes problem too.
> 
> It never reaches register_framebuffer. It leaves dh_regit at tese
> lines:
> 
>         else if (ACCESS_FBINFO(video.len) < mem) {
>                 kfree(d);
>                 return -ENOMEM;
>         }
> 
> ACCESS_FBINFO(video.len) is 2097152. Mem is 8388608.

Really... I did not notice in your original email that it
reports G400 as 2MB only device... Can you send me
output of 'lspci -s X:Y.Z -vvvxxx' (where X:Y.Z is
your G400 device, probably 1:00.0 or 2:00.0) with
2.4.19-pre10, and with Alan version? Alan's version
uses data from BIOS to set memory type, and it
apparently made mistake.

In Alan's kernel you should have option to enable procfs
interface - can you enable it and send me also
contents of /proc/driver/mga/fb*/pins. It is binary
file, if you want, you can parse it by matrox_pins
from ftp://platan.vc.cvut.cz/pub/linux/matrox-latest.
				Thanks,
					Petr Vandrovec
					vandrove@vc.cvut.cz


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Mixing g400 dualhead and old Millennium.

[Carlo E. Prelz]

	Subject: Re: Mixing g400 dualhead and old Millennium.
	Date: lun, ott 14, 2002 at 12:35:07 +0200

Quoting Petr Vandrovec (vandrove@vc.cvut.cz):

> Really... I did not notice in your original email that it
> reports G400 as 2MB only device... Can you send me
> output of 'lspci -s X:Y.Z -vvvxxx' (where X:Y.Z is
> your G400 device, probably 1:00.0 or 2:00.0) with
> 2.4.19-pre10, and with Alan version? Alan's version
> uses data from BIOS to set memory type, and it
> apparently made mistake.

So, the output from 2.4.19-pre10 is

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) (prog-if 00 [VGA])
	Subsystem: Matrox Graphics, Inc. Millennium G400 Dual Head Max
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at e8000000 (32-bit, prefetchable) [size=32M]
	Region 1: Memory at e4000000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at e5000000 (32-bit, non-prefetchable) [size=8M]
	Expansion ROM at e6000000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [f0] AGP version 2.0
		Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
00: 2b 10 25 05 02 00 90 02 04 00 00 03 08 40 00 00
10: 08 00 00 e8 00 00 00 e4 00 00 00 e5 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 7d 21
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 10 20
40: 20 00 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00
50: 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 f0 22 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 02 00 20 00 03 02 00 1f 00 00 00 00 00 00 00 00

The output from 2.4.19-pre10-ac2 differs in only one number. Here is the diff:

--- lspciold	Mon Oct 14 07:30:53 2002
+++ lspcinew	Mon Oct 14 07:35:09 2002
@@ -17,7 +17,7 @@
 10: 08 00 00 e8 00 00 00 e4 00 00 00 e5 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 7d 21
 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 10 20
-40: 20 00 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00
+40: 20 08 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00
 50: 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

> In Alan's kernel you should have option to enable procfs
> interface - can you enable it and send me also
> contents of /proc/driver/mga/fb*/pins. It is binary
> file, if you want, you can parse it by matrox_pins
> from ftp://platan.vc.cvut.cz/pub/linux/matrox-latest.

Info for the G400:

PINS from /proc/driver/mga/fb1/pins
  PINS:                          new, version 4.1, length 128
  DVD Info:                      FF
  Program date:                  C96C (2000-11-12)
  Program count:                 0003
  Product ID:                    0700
  Serial No:                     GAM73189        
  Part info:                     403   
  PCB info:                      38A4
  Max pixel VCO:                 360 MHz
  Max system VCO:                360 MHz
  Max CRTC1 VCO                  
    8bpp:                        360 MHz
    16bpp:                       360 MHz
    24bpp:                       360 MHz
    32bpp:                       360 MHz
  Max CRTC2 VCO                  
    16bpp:                       136 MHz
    32bpp:                       136 MHz
  OPTION flags:                  0xC2
  VGA Mode                       
    GClk VCO:                    328 MHz
    Reserved:                    29
    OPTION3 register:            0x0190A419
    MCTLWTST register:           0x20049911
    Clk1:                        standard
    Clk2:                        standard
  2D Mode                        
    GClk VCO:                    600 MHz
    Reserved:                    4B
    OPTION3 register:            0x019B8419
    MCTLWTST register:           0x20049911
  3D Mode                        
    GClk VCO:                    600 MHz
    Reserved:                    4B
    OPTION3 register:            0x019B8419
    MCTLWTST register:           0x20049911
  GClk Derate:                   FF
  MemRdBk:                       0C88
  MemRdBkMod:                    0C88
  VidCtrl:                       EE
  Factory options                
    Reference Freq:              27.000 MHz
    Memory size:                 32MB
    Memory type:                 SGLVTTL16
    MAVEN:                       present
    DVD:                         not present
    MJPEG:                       not present
    Decoder:                     not present
    Tuner:                       not present
    Audio:                       not present
    Panel Link:                  not present

I am also including info from the Millennium:

PINS from /proc/driver/mga/fb0/pins
  Product ID:                    0005
  Serial No:                     CAG81904  
  Manuf date:                    C0CC (1996-6-12)
  Manuf ID:                      0004
  PCB Info:                      49C3
  PMB Info:                      2642
  Ramdac speed:                  1
  Ramdac type:                   0
  Max PCLK:                      0
  Max LCLK:                      0
  ClkBase:                       5000
  Clk4MB:                        0
  Clk8MB:                        0
  ClkMod:                        0
  TestClk:                       0
  VGAFreq1:                      2517
  VGAFreq2:                      2832
  Program date:                  C4C8 (1998-6-8)
  Program count:                 5
  Ser No Ext:                    0F8B0000
  Feature flags:                 00000000
  VGA Clock:                     0
  Struct rev:                    0105
  Vid Ctrl:                      00
  Rsvd:                          00 00 00 00 00

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Mixing g400 dualhead and old Millennium.

[Petr Vandrovec]

On Mon, Oct 14, 2002 at 07:50:53AM +0200, Carlo E. Prelz wrote:
> --- lspciold	Mon Oct 14 07:30:53 2002
> +++ lspcinew	Mon Oct 14 07:35:09 2002
> @@ -17,7 +17,7 @@
>  10: 08 00 00 e8 00 00 00 e4 00 00 00 e5 00 00 00 00
>  20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 7d 21
>  30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 10 20
> -40: 20 00 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00
> +40: 20 08 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00

Oops.

>   OPTION flags:                  0xC2

Small mistake. Please apply patch below, it should fix your
problem.
						Best regards,
							Petr Vandrovec
							vandrove@vc.cvut.cz


--- linux-2.5.41-c748/drivers/video/matrox/matroxfb_misc.c.orig	2002-10-10 18:11:14.000000000 +0200
+++ linux-2.5.41-c748/drivers/video/matrox/matroxfb_misc.c	2002-10-14 14:50:29.000000000 +0200
@@ -849,7 +849,7 @@
 					  ( bd->pins[86]        & 0x0000000F);
 	MINFO->values.reg.opt		= ((bd->pins[53] << 15) & 0x00400000) |
 					  ((bd->pins[53] << 22) & 0x10000000) |
-					  ((bd->pins[53] << 10) & 0x00001C00);
+					  ((bd->pins[53] <<  7) & 0x00001C00);
 	MINFO->values.reg.opt3		= get_u32(bd->pins + 67);
 	MINFO->values.pll.system	= (bd->pins[ 65] == 0xFF) ? 200000 			: bd->pins[ 65] * 4000;
 	MINFO->features.pll.ref_freq	= (bd->pins[ 92] & 0x01) ? 14318 : 27000;


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Mixing g400 dualhead and old Millennium.

[Carlo E. Prelz]

	Subject: Re: Mixing g400 dualhead and old Millennium.
	Date: lun, ott 14, 2002 at 02:54:40 +0200

Quoting Petr Vandrovec (vandrove@vc.cvut.cz):

> Small mistake. Please apply patch below, it should fix your
> problem.

It does! Thanks.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf