Menu
▾
▴
linux-fbdev-devel
|
From: Carlo E. P. <fl...@fl...> - 2002-10-12 15:37:10
|
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 - fl...@fl... che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) |
|
From: Petr V. <van...@vc...> - 2002-10-13 00:16:25
|
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 |
|
From: Carlo E. P. <fl...@fl...> - 2002-10-13 14:15:42
|
Subject: Re: Mixing g400 dualhead and old Millennium. Date: dom, ott 13, 2002 at 02:13:24 +0200 Quoting Petr Vandrovec (van...@vc...): > 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 - fl...@fl... che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) |
|
From: Petr V. <van...@vc...> - 2002-10-13 14:56:28
|
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 van...@vc... |
|
From: Carlo E. P. <fl...@fl...> - 2002-10-13 15:14:38
|
Subject: Re: Mixing g400 dualhead and old Millennium. Date: dom, ott 13, 2002 at 04:56:04 +0200 Quoting Petr Vandrovec (van...@vc...): > 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 - fl...@fl... che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) |
|
From: Carlo E. P. <fl...@fl...> - 2002-10-13 16:08:06
|
Subject: Re: Mixing g400 dualhead and old Millennium.
Date: dom, ott 13, 2002 at 04:56:04 +0200
Quoting Petr Vandrovec (van...@vc...):
> 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 - fl...@fl... che bisogno ci sarebbe
* di parlare tanto di amore e di rettitudine? (Chuang-Tzu)
|
|
From: Petr V. <van...@vc...> - 2002-10-13 22:37:27
|
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 (van...@vc...):
>
> > 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
van...@vc...
|
|
From: Carlo E. P. <fl...@fl...> - 2002-10-14 05:51:09
|
Subject: Re: Mixing g400 dualhead and old Millennium. Date: lun, ott 14, 2002 at 12:35:07 +0200 Quoting Petr Vandrovec (van...@vc...): > 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 - fl...@fl... che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) |
|
From: Petr V. <van...@vc...> - 2002-10-14 12:54:50
|
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 van...@vc... --- 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; |
|
From: Carlo E. P. <fl...@fl...> - 2002-10-14 14:54:13
|
Subject: Re: Mixing g400 dualhead and old Millennium. Date: lun, ott 14, 2002 at 02:54:40 +0200 Quoting Petr Vandrovec (van...@vc...): > 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 - fl...@fl... che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) |
Thanks for helping keep SourceForge clean.
X