I have had a quick look at the Voodoo code in the latest DirectFB, and have some further questions which I hope someone may be able to answer.
If I were to use Voodoo to provide a client/server system on to the coprocessor, then I would need to build DirectFB server on the copro, which is non-linux based (Nucleus I think). I imagine this may be quite a difficult process, but has anyone done this or something similar? If so how long did it take? Would I need to implement some sort of Linux framebuffer abstraction for the nucleus system, plus OS abstractions for things like pthreads which I see is extensively used. I would need to replace the socket based communications from client to server with the copro equivalent message passing. I think this may just be a matter of replicating, the socket calls with appropriate copro calls, but again, does anyone out there have experience of this? Either that or I implements sockets over the copro link, which may in fact be useful in other parts of the project. As to the build itself, am I right in thinking that currently the voodoo build makes both the client and the server side code, resulting in a thin library for the client, and the main DirectFB code for the server - all using the same architecture? I am guessing I would need to change the build in to two distinct areas, one to compile for the Linux client, one to compile (if possible) for the Nucleus host. Thansk for any advice, Rgds James 9/22 James Hughes <[EMAIL PROTECTED]>: > Hi Niels > > That sounds exactly what I need. May need to move from IP to another message > passing process (copro has its own message system), but otherwise does sound > very hopeful. > > Thanks > > James > > > Niels Roest wrote: >> >> Hi James. >> >> You might want to take a look at voodoo (part of DirectFB core). >> With this you can have a DirectFB acting as server running on your copro, >> and a DirectFB acting as client running on your main proc. >> voodoo simply passes all calls along. >> You need to figure out a bit what to do with your mem tho. >> Current implementation uses IP sockets. >> >> Greets >> Niels >> >> James Hughes wrote: >> >>> >>> 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 >>> >>> >> >> >> > > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
