Re: [Linux-fbdev-devel] Re: kernel: matrox fb - missing files, doesn't compile

[Petr V. <van...@vc...>]

On Sun, Dec 15, 2002 at 05:30:43AM +0500, Antonino Daplas wrote:
> On Fri, 2002-12-13 at 15:09, Petr Vandrovec wrote:
> > Current interface just supports only cfb, and only very bad for my needs.
> > And because of matroxfb supports also other modes (such as native text
> > mode, or loading font into accelerator), bye-bye. For now I recommend you 
> > either to not upgrade, or use vesafb. Besides that accel_putcs() does not 
> > call fb_sync when using font width which is not multiple of 8, and that 
> Can you explain why an fb_sync is needed for every character?

It is not needed after every character. But I thought that it will be called
before we return to userspace... And I want to rely on fb_sync
because of hardware setup to change fg_color and bg_color is very costly.

In my tests I'm not able to get accelerated code running faster than
at 50% of old speed with 12x22 font, and I'm hoping that eliminating these
two PCI writes could speed it a bit... It will not get on par, but better than
nothing.
 
> > with fonts greater than 16*16 pixels (I believe that such fonts are still 
> > supported...) it will corrupt memory...
> 
> I agree.  To be more specific, buffer overruns will occur if (xres *
> fontheight/8 > 8192).  The pixmap needs to be dynamically allocated and
> resized somewhere in the fbcon layer (ideally in accel_setup(), but this
> was removed).  For those concerned about this problem, you can try this
> patch as a temporary measure until fbcon is fixed. It should not cause
> to much slowdown:

But we may try to allocate buffers of order 2 or even 3 with kmalloc, and
if I remember fork() problems with allocating stack with order=1 correctly,
it is not best idea under the sun. But using physically non-continuous
area is probably even worse idea.

> For anyone concerned, this is a heads up:  The data in the pixmap must
> be read completely by the hardware before exiting, otherwise font
> corruption will occur.  If you think this will be a problem, the
> function can be easily modified to do multiple buffering instead.

What if I'll decide to paint characters through busmastering? Then
I need font data in buffers allocated by pci_alloc_consistent...
In the past it was not a win to use busmastering, but now, when
upper layers might prepare images much larger than 8x16, it may be 
worth of rechecking that...
					Best regards,
						Petr Vandrovec
						van...@vc...