Messages in this thread | | | Date | Thu, 03 Feb 2005 09:36:29 +0100 | From | Helge Hafting <> | Subject | Re: Accelerated frame buffer functions |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |