From: Petr V. <VAN...@vc...> - 2002-10-16 07:18:58
|
On 16 Oct 02 at 2:08, Javier Marcet wrote: > > I patched my kernel with fbset-through-vt-2.4.19-rc5.gz, > mga-2.4.19-rc5-tvout.gz was already merged by Alan Cox on his tree. > However I get oopses often when using a console on my TV if I am playing > with matroxset & fbset, which I am right now as I am polishing some > scripts and default config files to include in the package for Gentoo. > I have just removed it from my kernel and I'll see if the oopses show up > again. Make sure that you boot with 'video=scrollback:0' if you have more than one head... It is also very dangerous to use 'fbset -fb /dev/fbX' in multihead environment, because of PROC_CONSOLE() returns vt number from the VT for the process, happilly passing VT initialized by vga16 or primary head of matroxfb to secondary head. And secondary head is certainly surprised if it is invoked on console saying 8bpp, while it supports only 16/32... If you'll use 'fbset -fb /dev/ttyX', no oops should occur. > I tried matroxfb-vsync-irq-patch-2.4.19 too, but with it I cannot use at > all any board on my first PCI slot since the Matrox is using the IRQ. > What is the patch good for? I just have a crowded PC and no free slots. I did not wrote that patch... Make sure that request_irq() is done for shared irq, Matrox hardware has no problem with sharing irq, and if irq handler in matroxfb-vsync-irq-patch is written correctly, it should just work. > I send attached two of the scripts I've written. There is something > which I could not yet understand. > If you run 'mgafb.sh pal fb1 4' to set fb1 in pal mode and control > virtual console 4, in principle works just fine. If I run it from > tvgetty.sh from inittab there aren't any kind of problems, but if I > launch it from another console, the first time works as expected, but > after the first one, not only console 4 changes of mode, but the console > I am calling it from also changes to pal mode. > I couldn't understand why. DO you see any reason? Yes. Second time it will call secondary's head set_var with console argument 0, because of PROC_CONSOLE() will return that... Use 'fbset -fb /dev/tty4', and all problems will magically disappear. I'm using #! /bin/bash set -e con2fb /dev/fb1 /dev/tty8 fbset -fb /dev/tty8 1280x1024-60 -depth 16 fbset -fb /dev/tty8 -vyres 3276 matroxset -f /dev/fb0 -m 2 matroxset -f /dev/fb1 -m 5 chvt 8 and it works as one expect... > Besides, if you read tvgetty.sh, you'll see a line with 'setfont'. > That's because without it I do not get 8bit mode on that console, and > thus can't see extended characters. Is it normal that I have to > re-run that kind of init scripts, which are system-wide (for all the > consoles) on my system, for the second head? Probably. Console subsystem tends to load default font to the tty on mode sets: look at fbcon_setup: it will find whether some other VT on specified fb uses some font, then it releases current font, and now, if it found some font in previous step (i.e. at least two VTs use this fbdev...), it will copy this font to the VT in question, otherwise it will try fbdev default font (as specified by video=matrox:font:...), or system global default font (fbcon_get_default_font()). Petr Vandrovec van...@vc... |