Re: Accelerated frame buffer functions

[Helge Hafting <helge.hafting@hist.no>]

Haakon Riiser wrote:

>[Geert Uytterhoeven]
>
>  
>
>>mmap() the MMIO registers to userspace, and program the
>>acceleration engine from userspace, like DirectFB (and XF*_FBDev
>>3.x for Matrox and Mach64) does.
>>    
>>
>
>Right, this was how I originally intended to do it.  The reason
>why I started to obsess about the accelerated fb_ops functions was
>that I hoped that, by creating a driver that registered accelerated
>versions of these functions, other frame buffer-using applications
>would instantly take advantage of it, requiring no changes in those
>applications.  
>
The only framebuffer interface I know of is the framebuffer console.
It uses the fbdev acceleration when writing character strings
and scrolling.  So if your app writes data on the console and/or
scroll regions, then it certainly uses framebuffer acceleration.

>I thought the frame buffer device was supposed to
>serve as an an abstraction layer between the graphics card and
>the application, allowing for 2D acceleration without having to
>know anything about the underlying hardware.  But if no one uses the
>frame buffer device in this way, I might as well do as you suggest
>and mmap() the registers to userspace.
>  
>
I believe you also can write a small driver that connects to the
framebuffer the same way the fbconsole does.  It could then
export all the operations so userspace actually can call them.  This
have the advantage that your app can work on more than just one kind of
framebuffer.  Perhaps you run on one kind of hardware only today,
but who knows what hardware the future will bring?  Nice not having
to rewrite it all. . .

Helge Hafting