Messages in this thread | | | From | "Petr Vandrovec Ing. VTEI" <> | Date | Mon, 28 Jun 1999 22:00:23 MET-1 | Subject | Re: Framebuffer question. (62 lines) |
| |
Modemch <serge@ectaco.com> wrote: > There are a few problems with the matrox framebuffer, one of them was > mentioned on the list - it locks up the machine if you try to scroll up > (shift-pageup) while something is scrolling down. Hi, this one is caused by changes in 2.2.3 (or 4) where software scrollback was introduced into kernel. It causes that video drivers are regulary reentered (if something is scrolling) and no-one told me that it is possible when I wrote matroxfb - it was guaranteed (and AFAIK no one changed position on this because it is impossible to write reentrant hardware driver without spinlock_irqsave - and we do not want irqsave for couple of milliseconds) that all fbdev procedures all call with (1) CONSOLE_BH disabled or (2) from console_bh (or (3) from printk()). Patch is available at ftp://vana.vc.cvut.cz/private/fbdev/consolefix.diff.gz but because of this does not touch my code, I pointed console maintainer to this. But mj@ucw.cz told me that I should not call disable_bh() in set_cursor and do it in upper levels instead. And because of I have to do some work for my employer... Booting with 'video=scrollback:0' fixes this problem too (unless you have software cursor). So if you have spare time, feel free to build correct (and complete) patch. If you'll boot with 'video=matrox:fastfont:40000', matroxfb will use BITBLT instead of ILOAD to draw characters. It decreases probability of crash (ILOAD consist of write accesses to Matrox which must not be interleaved with other accesses to Matrox (value written to ANY control register is taken as character data, read causes PCI bus deadlock), BITBLT simple draws without interaction with CPU (matrox-i2c has also busmastering bitblt on G100/G200, but it is slower than ILOAD on my hardware). In same directory you can also find file matrox-i2c.gz which contain DDC interface (not important for you...) and reentrancy checks (this is important for you) if you have i386 (I'm using printstate() to print callstack and so on and because of I wrote i386 version only...)). > I've noticed a few more, > like garbled characters, and screen going blank if you switch to a console > running less, and press the up arrow. I thought I could try to fix these, > but ran into a problem right away. 'video=scrollback:0'. I think that problem is not on my side, but Jakub Jelinek did not reply and that scrollback code is beyond my knowledge (did you ever tried to press shift-pgdn when logo is shown?). Maybe that these strange characters has something to do with reentering fbcon itself (as no problem with 'less' here). > It is possible to compile the > framebuffer as a module, but I have no clue how it can be removed after > it's inserted - naturally, rmmod doesn't work as the module is being used > by all the consoles. Is there a way to actually remove or reload it, and > if not, what's the point of having a framebuffer driver as a module? Compile vfb into kernel and boot with 'video=vc:5,6'. Then, after boot, VT5 and 6 should appear non-working. So now you can insmod matroxfb and do 'con2fb /dev/fb1 /dev/tty5' and test it. After you compile new matroxfb, you can 'con2fb /dev/fb0 /dev/tty5; rmmod matroxfb; insmod matroxfb; con2fb /dev/fb1 /dev/tty5' (con2fb.c.gz is at ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/con2fb.c.gz).
Jeff Garzik wrote: > For the other things you mention, you should contact the matroxfb > maintainer, Petr Vandrovec, listed at the top of matroxfb.c. Petr has > some matroxfb updates that are not yet in the kernel, perhaps using his > test version would solve your problem. I'm reading linux-kernel-digest, so there is a small delay. And today I had to read weekend volumes too... 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/
| |