Re: Matrox G400 Dual Head

From: Petr Vandrovec (VANDROVE@vc.cvut.cz)
Date: Mon Feb 28 2000 - 06:46:02 EST


On Sun 27, 2000 German Jose Gomez Garcia wrote:
> Monitor -> Monitor works perfectly
Well.
> NTSC -> PAL works but no color!?!?
Do you have NTSC tv? If not, then no color...
> PAL -> PAL I get color but I also get horizontal green bars
> they seem to xor the normal image.
It is expected, if you did not change resolution. 640x480 contains only
525 lines, but MGA-TVO is not able to upscale picture to 625 lines
needed by PAL. So scaller is programmed to 1:1 - and sometime it has
to `invent' data itself. Run 'fbset -yres 580' and green bars
disappear. There is small notice 10 lines from the end of
Documentation/fb/matroxfb.txt, which says this...
> Other thing I would like to know is if it is normal than when you
> switch virtual console the image on the second output gets frozen and
> isn't updage until you change to the original console. For example if I
> try fbtv using the dualhead (I know ... TV on TV isn't new :-) the image
It does fbtv itself. You have to add parameter '-k'. console signaling
to apps about receiving/loosing focus have to be changed a bit.
> on the monitor gets frozen when I change the virtual console to one
> different that the console from which I launch the fbtv program.
Kernel code does not handle multihead very safe - I have patch, which
you should apply, if you are going to really use multihead. There were
some promises in late 2.1.x times to fix it different way than mine for 2.4,
but... nothing happened yet.
So, please, download from ftp://platan.vc.cvut.cz/pub/linux/matrox-latest
multihead.gz and apply it to your kernel (patch was created from 2.3.48),
fbset-2.1.tar.gz and unpack,
fbset-2.1-addon.gz and unpack & apply to fbset-2.1 sources,
con2fb.c.gz, unpack & compile,
recompile kernel and fbset, reboot
  After reboot, kernel will refuse attempts to change mode which could
cause bad problems (oops) under older kernels - for example changing
resolution of /dev/fb1 while active tty belongs to /dev/fb0 and
vice versa. To get around this limitation, there is new parameter to
fbset, '-vt X' - it says which VT to modify. 1..64 have usual meaning,
0=current vt and -1 = default resolution of that fb (it is used when
there is no VT attached to that fb; for example after boot, before
first con2fb). I believe that it will fix all your problems with suspended
output.
  Before you'll try to use this fbset with other drivers than matrox, verify
that their set_var procedure is fully compliant to fbdev specs - i.e.
when con != visible, do not touch hardware. vesafb & vga16fb should be
safe too, I do not know about others.
                                    Best regards,
                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz
                                            

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:19 EST