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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
