Menu
▾
▴
linux-fbdev-devel
|
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...
|
|
From: Petr V. <VAN...@vc...> - 2002-10-16 16:01:44
|
On 16 Oct 02 at 17:33, Javier Marcet wrote:
> * Petr Vandrovec <VAN...@vc...> [021016 09:19]:
>
> >> 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'
>
> By more than one head you mean more than one physical card? Ot does my
> G400MAX with its two heads count as more than one?
It counts as two if you are using /dev/fb1...
> >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...
>
> One strange thing I've seen though, is that I cannot use 'fbset -depth
> xx' with xx other than 32 or I'll get:
> 'ioctl FBIOPUT_VSCREENINFO: Invalid argument'
16bpp should work too on second head.
> >If you'll use 'fbset -fb /dev/ttyX', no oops should occur.
>
> Whenever I try to pass a tty as argument to the -fb option I get the
> same error I wrote above.
16bpp and 32bpp should work. Because of values in default /etc/fb.modes
are with 8bpp, you must use 'fbset 1024x768-60 -depth 32'. And if
you are using Debian (maybe it is problem with stock fbset, I did not
verified it), make sure that videomode 1024x768-72 in /etc/fb.modes
does not use 10224 as xres/vxres... Most of monitors and videocards does
not handle xres=10224 properly. You need dozen of megabytes vram to
use this mode...
> >> 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 know it is not a problem of the card itself, since without that patch
> I don't have problems, but with it whenever a card on the 1st PCI tries
> to use an IRQ, say a NIC card which is enabled by a 'if eth0 up', the
> system blocks. No output, no sysrq, nothing, just a solid freeze.
Maybe that it enables IRQ on card before installing IRQ handler.
In such case nobody is going to clear IRQ in mga IRQ status register,
and your system is processing endless stream of interrupts. Buying
another CPU may give you chance to debug it. Or if you'll send
me pointer to the patch, I can review it...
> BTW, of the other two patches available, what is the one quoted at the
> top of this message for? I have removed it and since then I get no more
> locks when heavily using my second head, which was specially sensitive
> when doing lots of 'fbset', 'matroxset' et all.
Which one? fbset-through-vt? It should not change behavior of
fbset when using 'fbset -fb /dev/fb*', it just adds possibility
to use 'fbset -fb /dev/tty*' to set videomode on specific virtual
terminal. And it should not cause any behavior changes to matroxset.
If mga-*-tvout, it adds support for DVI-D and TV outputs available
on G450/G550.
> >> 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
>
> >set -e
>
> What is this for? emacs mode?
> I use 'set -vi' :)
Stop on error... so in your case it will stop just immediately
after fbset will fail, instead of performing (now useless and
dangerous) second fbset, matroxset, and chvt.
> >con2fb /dev/fb1 /dev/tty8
>
> This is the command less problems has given to me ;-) Simple code and
> apparently bug-free :)
>
> >fbset -fb /dev/tty8 1280x1024-60 -depth 16
> >fbset -fb /dev/tty8 -vyres 3276
>
> I cannot do that, or else I'll get the 'ioctl FBIOPUT_VSCREENINFO:
> Invalid argument'. The only way I've found is to switch to the desired
> vt, and run fbset there.
Do you have 16MB or 32MB device? -vyres 3276 will work only if
you have 8MB available for second head. With 16MB device maybe
only 7.9MB is available for second head. And of course, you must have
fbset-through-vt patch in your kernel, otherwise you'll get -EINVAL
too.
> >> 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()).
>
> That was it, I have to change the font on fb1 at least once and it'll be
> in effect from there on on any vt open on fb1.
OK.
> Another question. To get a fast vertical scroll I have to run with a
> bigger virtual yres than real's. Is this normal?
Yes. With yres=vyres you cannot use hardware panning, hardware must
always move full screen 16 graphics lines up. Even if MGA core
can transfer 1GBps, it takes some time to scroll 3MB (for 1024x768/32bpp)
up - to scroll out all 48 lines it is 144MB read + 144MB written...
> Also, with fastfonts
> enabled, it's terribly slow, while in the kernel documentation it's
> stated than fastfonts is faster on Gx00 cards.
> Has that anything to do with the scrollback you told me before? I have
> not tried it yet.
No. fastfont should be used only on G200 (if anywhere...). On G200
you'll get about 10% speed gain, on older chips about 10% slowdown.
But (for unknown reason...) on G400 you'll get about 1000% slowdown.
Maybe I should rerun benchmarks listed in Documentation/fb/matroxfb.txt
also on newer hardware.
> Anyway, thanks, and I mean a BIG thanks for your detailed quick and
> prompt response. I wish I got such a nice help with a bttv/DVB cards
> problem I cannot solve.
Buy me one... if it is terrestric digital broadcast, maybe I could
even receive some digital signal here.
Petr
|
|
From: Javier M. <jm...@po...> - 2002-10-16 16:52:56
|
* Petr Vandrovec <VAN...@vc...> [021016 18:02]: >> By more than one head you mean more than one physical card? Or does my >> G400MAX with its two heads count as more than one? >It counts as two if you are using /dev/fb1... OK. >> One strange thing I've seen though, is that I cannot use 'fbset -depth >> xx' with xx other than 32 or I'll get: >> 'ioctl FBIOPUT_VSCREENINFO: Invalid argument' >16bpp should work too on second head. I can only use 32 bits. Don't ask me why. >> >If you'll use 'fbset -fb /dev/ttyX', no oops should occur. >>=20 >> Whenever I try to pass a tty as argument to the -fb option I get the >> same error I wrote above. >16bpp and 32bpp should work. Because of values in default /etc/fb.modes >are with 8bpp, you must use 'fbset 1024x768-60 -depth 32'. And if >you are using Debian (maybe it is problem with stock fbset, I did not >verified it), make sure that videomode 1024x768-72 in /etc/fb.modes >does not use 10224 as xres/vxres... Most of monitors and videocards does= =20 >not handle xres=3D10224 properly. You need dozen of megabytes vram to >use this mode... I have my custom fb.modes, indeed I'm trying to provide find some nice default values to include in the package I'm writing for Gentoo, which is the distribution I use, http://www.gentoo.org Free and completely open source as Debian, but source based. >> >> I tried matroxfb-vsync-irq-patch-2.4.19 too, but with it I cannot use= at >> I know it is not a problem of the card itself, since without that patch >> I don't have problems, but with it whenever a card on the 1st PCI tries >> to use an IRQ, say a NIC card which is enabled by a 'if eth0 up', the >> system blocks. No output, no sysrq, nothing, just a solid freeze. >Maybe that it enables IRQ on card before installing IRQ handler. >In such case nobody is going to clear IRQ in mga IRQ status register, >and your system is processing endless stream of interrupts. Buying >another CPU may give you chance to debug it. Or if you'll send >me pointer to the patch, I can review it... You mean the patch that gives the problem or .. what? It's the vsync-irq-patch on your ftp server. >Which one? fbset-through-vt? It should not change behavior of >fbset when using 'fbset -fb /dev/fb*', it just adds possibility >to use 'fbset -fb /dev/tty*' to set videomode on specific virtual >terminal. And it should not cause any behavior changes to matroxset. Oh, I see. That's what I wanted to know exactly, what that patch was exactly for. Now it's everything more clear :) >If mga-*-tvout, it adds support for DVI-D and TV outputs available >on G450/G550. OK, I don't need that one but it's already included in -ac branch. Maybe Alan agrees to include the fbset-through-vt one too, even if Marcelo, or whoever, refused to include it. >> >set -e >> What is this for? emacs mode? >Stop on error... so in your case it will stop just immediately >after fbset will fail, instead of performing (now useless and >dangerous) second fbset, matroxset, and chvt. I'll add it then. >> I cannot do that, or else I'll get the 'ioctl FBIOPUT_VSCREENINFO: >> Invalid argument'. The only way I've found is to switch to the desired >> vt, and run fbset there. >Do you have 16MB or 32MB device? -vyres 3276 will work only if >you have 8MB available for second head. With 16MB device maybe >only 7.9MB is available for second head. And of course, you must have I have 32MB device. G400MAX DH. The best one IMHO that matrox did of the G4xx series. >Yes. With yres=3Dvyres you cannot use hardware panning, hardware must >always move full screen 16 graphics lines up. Even if MGA core >can transfer 1GBps, it takes some time to scroll 3MB (for 1024x768/32bpp) >up - to scroll out all 48 lines it is 144MB read + 144MB written... I see, then my assumptions were correct. >> Also, with fastfonts >> enabled, it's terribly slow, while in the kernel documentation it's >> stated than fastfonts is faster on Gx00 cards. >> Has that anything to do with the scrollback you told me before? I have >> not tried it yet. >No. fastfont should be used only on G200 (if anywhere...). On G200 >you'll get about 10% speed gain, on older chips about 10% slowdown. >But (for unknown reason...) on G400 you'll get about 1000% slowdown. >Maybe I should rerun benchmarks listed in Documentation/fb/matroxfb.txt >also on newer hardware. Tell me if you wanna have results from other systems. >> Anyway, thanks, and I mean a BIG thanks for your detailed quick and >> prompt response. I wish I got such a nice help with a bttv/DVB cards >> problem I cannot solve. >Buy me one... if it is terrestric digital broadcast, maybe I could >even receive some digital signal here. Believe me, I would. But being a student with nearly zero income, I just can't. Indeed, getting a different DVB card might give me some pointer to where the problem is. The thing is that without my DVB card installed on the system, I can use the bttv analog TV card just fine. The kernel recognizes it as a 'WinTV Go' - it's one of the two bttv cards I have over here -, and it works. However, once I plug the DVB in a PCI slot, anyone of them, the bttv card is not even recognized by the kernel. With both cards inserted I get this out of 'lspci -v': 00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH: Unknown device 0000 Flags: bus master, medium devsel, latency 32, IRQ 15 Memory at de800000 (32-bit, non-prefetchable) [size=3D512] 00:0c.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capt= ure (rev 11) Subsystem: Unknown device 0030:13eb Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at e1000000 (32-bit, prefetchable) [size=3D4K] Capabilities: [04] #06 [0290] 00:0c.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (r= ev 11) Subsystem: Unknown device 0030:13eb Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at e0800000 (32-bit, prefetchable) [size=3D4K] Capabilities: [04] #06 [0290] Whereas if I remove the DVB card, the output is: 00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capt= ure (rev 11) Subsystem: Hauppauge computer works Inc. WinTV/GO Flags: bus master, medium devsel, latency 32, IRQ 15 Memory at e1000000 (32-bit, prefetchable) [size=3D4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (r= ev 11) Subsystem: Hauppauge computer works Inc. WinTV/GO Flags: bus master, medium devsel, latency 32, IRQ 15 Memory at e0800000 (32-bit, prefetchable) [size=3D4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 The most strange thing is that in the past I know they worked under Windows at the same time, and I believe I once made them work in Linux at the same time. I've tried kernels from 2.4.18 to latest 2.4.20-pre, I've come back several revisions of my BIOS, everything. They just cannot coexist on my system at the same time. When I try to use the bttv when it's not correctly recognized, I can load the bttv modules and the card is found, yet If I try to use it, I can only get sound and lots of SYNC IRQ problems with my SCSI card: Oct 15 00:51:22 [kernel] bttv0: registered device video0 Oct 15 00:51:33 [kernel] scsi0: PCI error Interrupt at seqaddr =3D 0x9 Oct 15 00:51:33 [kernel] bttv0: irq: SCERR risc_count=3D12670014 Oct 15 00:51:33 [kernel] bttv0: irq: SCERR risc_count=3D12670014 Oct 15 00:51:38 [kernel] bttv0: resetting chip Oct 15 00:51:38 [kernel] scsi0: PCI error Interrupt at seqaddr =3D 0x8 Oct 15 00:51:38 [kernel] bttv0: irq: SCERR risc_count=3D12670014 Oct 15 00:51:38 [kernel] bttv0: irq: SCERR risc_count=3D12670014 Oct 15 00:51:38 [kernel] scsi0: PCI error Interrupt at seqaddr =3D 0x9 Oct 15 00:51:38 [kernel] bttv0: irq: SCERR risc_count=3D12670000 This is of course without having loaded any DVB driver. All right, forgive me for the off-topic. I might make it somewhat on-topic by saying that the errors above were using 'fbtv' which uses the framebuffer to show the TV signal. --=20 Javier Marcet <jm...@po...> Saint Louis University, Madrid Campus |
|
From: Petr V. <VAN...@vc...> - 2002-10-16 18:19:41
|
On 16 Oct 02 at 18:53, Javier Marcet wrote:
> >> One strange thing I've seen though, is that I cannot use 'fbset -depth
> >> xx' with xx other than 32 or I'll get:
> >> 'ioctl FBIOPUT_VSCREENINFO: Invalid argument'
>
> >16bpp should work too on second head.
>
> I can only use 32 bits. Don't ask me why.
Do you have compiled 16bpp into kernel? And if everything else
fails, what does '-depth 16 -rgba 5,6,5' or '-depth 16 -rgba 5,5,5,1'?
> >Maybe that it enables IRQ on card before installing IRQ handler.
> >In such case nobody is going to clear IRQ in mga IRQ status register,
> >and your system is processing endless stream of interrupts. Buying
> >another CPU may give you chance to debug it. Or if you'll send
> >me pointer to the patch, I can review it...
>
> You mean the patch that gives the problem or .. what? It's the
> vsync-irq-patch on your ftp server.
Hm...
platan:~# cd ~ftp
platan:/home/ftp# find -name '*irq*'
platan:/home/ftp#
so I have to ask stupid question... where is my ftp server?
> >If mga-*-tvout, it adds support for DVI-D and TV outputs available
> >on G450/G550.
>
> OK, I don't need that one but it's already included in -ac branch.
> Maybe Alan agrees to include the fbset-through-vt one too, even if
> Marcelo, or whoever, refused to include it.
mga-*-tvout allows 'v4lctl -c /dev/fb0 xxxx' to set brightness/contrast
on TV output. I'm not sure whether Alan merged this too or not,
as it uses v4l2 interface, which is not in the kernel yet (and as it
stands, v4l2 is not going to 2.6.x too).
> >Maybe I should rerun benchmarks listed in Documentation/fb/matroxfb.txt
> >also on newer hardware.
>
> Tell me if you wanna have results from other systems.
I'll try to create some selfcontained benchmark.
> 00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
> Subsystem: Technotrend Systemtechnik GmbH: Unknown device 0000
> Flags: bus master, medium devsel, latency 32, IRQ 15
> Memory at de800000 (32-bit, non-prefetchable) [size=512]
>
> 00:0c.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
> Subsystem: Unknown device 0030:13eb
> Flags: bus master, medium devsel, latency 32, IRQ 11
> Memory at e1000000 (32-bit, prefetchable) [size=4K]
> Capabilities: [04] #06 [0290]
>
> 00:0c.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
> Subsystem: Unknown device 0030:13eb
> Flags: bus master, medium devsel, latency 32, IRQ 11
> Memory at e0800000 (32-bit, prefetchable) [size=4K]
> Capabilities: [04] #06 [0290]
>
> Whereas if I remove the DVB card, the output is:
>
> 00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
> Subsystem: Hauppauge computer works Inc. WinTV/GO
> Flags: bus master, medium devsel, latency 32, IRQ 15
> Memory at e1000000 (32-bit, prefetchable) [size=4K]
> Capabilities: [44] Vital Product Data
> Capabilities: [4c] Power Management version 2
>
> 00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
> Subsystem: Hauppauge computer works Inc. WinTV/GO
> Flags: bus master, medium devsel, latency 32, IRQ 15
> Memory at e0800000 (32-bit, prefetchable) [size=4K]
> Capabilities: [44] Vital Product Data
> Capabilities: [4c] Power Management version 2
I know that you'll not believe me, but your DVB card has hardware
problem: it grounds pin DATA6 of PCI bus to zero: so it gets 04 instead
of 44 from capabilities, 0030 instead 0070 from subsystem vendor
ID...
I cannot explain why busid changed for your Bt878: if it would move
from 0A to 02, or disappeared completely, I could understand it...
but move from 0A to 0C? Sorry...
Petr
|
|
From: <sy...@sc...> - 2002-10-16 18:27:42
|
On Wed, Oct 16, 2002 at 08:19:10PM +0200, Petr Vandrovec wrote: > > You mean the patch that gives the problem or .. what? It's the > > vsync-irq-patch on your ftp server. > > Hm... > > platan:~# cd ~ftp > platan:/home/ftp# find -name '*irq*' > platan:/home/ftp# > > so I have to ask stupid question... where is my ftp server? I'd say it's probably from DirectFB. -- Ville Syrjälä sy...@sc... http://www.sci.fi/~syrjala/ |
|
From: Javier M. <jm...@po...> - 2002-10-16 15:33:23
|
* Petr Vandrovec <VAN...@vc...> [021016 09:19]: >> 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=3Dscrollback:0' if you have more >than one head... It is also very dangerous to use 'fbset -fb /dev/fbX' By more than one head you mean more than one physical card? Ot does my G400MAX with its two heads count as more than one? >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... One strange thing I've seen though, is that I cannot use 'fbset -depth xx' with xx other than 32 or I'll get: 'ioctl FBIOPUT_VSCREENINFO: Invalid argument' =09 >If you'll use 'fbset -fb /dev/ttyX', no oops should occur. Whenever I try to pass a tty as argument to the -fb option I get the same error I wrote above. >> 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 know it is not a problem of the card itself, since without that patch I don't have problems, but with it whenever a card on the 1st PCI tries to use an IRQ, say a NIC card which is enabled by a 'if eth0 up', the system blocks. No output, no sysrq, nothing, just a solid freeze. BTW, of the other two patches available, what is the one quoted at the top of this message for? I have removed it and since then I get no more locks when heavily using my second head, which was specially sensitive when doing lots of 'fbset', 'matroxset' et all. >> 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...=20 >Use 'fbset -fb /dev/tty4', and all problems will magically disappear. >I'm using >set -e What is this for? emacs mode? I use 'set -vi' :) >con2fb /dev/fb1 /dev/tty8 This is the command less problems has given to me ;-) Simple code and apparently bug-free :) >fbset -fb /dev/tty8 1280x1024-60 -depth 16 >fbset -fb /dev/tty8 -vyres 3276 I cannot do that, or else I'll get the 'ioctl FBIOPUT_VSCREENINFO: Invalid argument'. The only way I've found is to switch to the desired vt, and run fbset there. >> 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=3Dmatrox:font:...), or system global default >font (fbcon_get_default_font()). That was it, I have to change the font on fb1 at least once and it'll be in effect from there on on any vt open on fb1. Another question. To get a fast vertical scroll I have to run with a bigger virtual yres than real's. Is this normal? Also, with fastfonts enabled, it's terribly slow, while in the kernel documentation it's stated than fastfonts is faster on Gx00 cards. Has that anything to do with the scrollback you told me before? I have not tried it yet. Anyway, thanks, and I mean a BIG thanks for your detailed quick and prompt response. I wish I got such a nice help with a bttv/DVB cards problem I cannot solve. --=20 Javier Marcet <jm...@po...> Saint Louis University, Madrid Campus |
Thanks for helping keep SourceForge clean.
X