Re: Framebuffer question. (62 lines)
Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Mon, 28 Jun 1999 22:00:23 MET-1
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/