Hello all, I have been asked to look in to DirectFB on an embedded system, with an embedded coprocessor which has acceleration for 2D/3D/Video/HD. A customer wants to use the 2D acceleration features, but I am having trouble figuring out the architecture required. I'll explain why.
The LCD panel is attached to the coprocessor and not to the host processor, which means the host has no access direct to the frame buffer memory. We do have LCD and Linux framebuffer drivers for the coprocessor, which currently work by having a local copy of the framebuffer data, which is copied to other coprocessor, either on each change or on a timer. However this scheme means no acceleration of the 2d functions since they have to be done on the coprocessor (3D and other stuff is compositied on the coprocessor), so the frame would have to be moved back and forth from the coprocessor, which rather wrecks any performance gains from using the acceleration. One option may be to port the entire DirectFB system to the coprocessor - accelerating those functions the coprocessor support, using default DirectFB to handle the rest, and having a RPC like arrangement to pass DirectFB commands to the coprocessor, but I am not sure whether this would be possible, and there is a lot of work required in making the wrapper layer to DirectFB via message passing RPC. Does anyone have any thoughts on the correct architecture for a system such as this? Or can point me in the direction of documents that may give me a better understanding of what may be required? Or have I got hold of completely the wrong end of the stick and have missed something obvious? TIA. James _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
