Hi Niels, Thanks for spending the time replying. Much appreciated.
Unfortunately we don't use gcc on the copro- ARC Metaware I think. This could be the biggest stopper. Puts dev time up to months rather than weeks I would imagine, plus all the other work required. Thanks again for all the 'food for thought' Rgds James 2008/9/23 Niels Roest <[EMAIL PROTECTED]>: > > James Hughes wrote: >> >> 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. >> >> > > Not having experience with the porting as such to non-linux, > but will write down some thoughts. > > Looks like a task-based RTOS. > for pthreads, pthread task handling is abstracted in lib/direct/thread.c. > The other occurences are mainly to do with mutex (un)locking. > This should be relatively straight-forward to tackle. > > Frame buffer abstraction is not necessary if you use devmem, > but then you will need to program some similar code using inside a system > module. > This is not much but rather more complex. > > And you better had a gcc compiler.. > > I think, in all, this should be doable. >> >> 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. >> >> > > You will need to change the voodoo library. > This is all abstracted so that should not generate complex issues. > >> 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. >> >> > > For the client, you need the voodoo and direct libs (so not directfb lib). > This is all generic, so you also need something to register the interfaces > besides, but that's limited. > For the server you will need the complete DirectFB stack. > Of the issues here, this should be the least of your concerns I think. > >> Thansk for any advice, >> >> Rgds >> >> James >> >> > > hth, > Niels > > -- > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
