Hi, On my platform, I need to move the voodoo renderer (server) to a simple (mmu less) RTOS, serving requests from a DFB client applications running on a processor having linux kernel, are these the things I need to port: 1. voodoo underlying IP socket communication with something else (Shared memory ?) 2. Fusion kernel module to user space fusion. 3. Underlying systems fbdev to be replaced with RTOS render functionality
First is the above correct and logical way to proceed. If anyone has prior experience with such an architecture can you please highlight the pitfalls faced. Second, In an ordinary (single processor) DFB world with no libvoodoo, the first DFB app becomes the server and takes control of the input devices, ttyx and fb. DFB apps starting up after the this first one assume the role of a slave and communicate their rendering requests to the server via fusion. Does this also apply in libvoodoo (over RTOS) environment, where the first DFB app (running on linux) becomes master, or all DFB apps have same role to play. For example, which DFB app can read input and ttyx device events. Third, on my platform with framebuffer being a shared memory between the two processors, Is it possible that I choose only specific operations that should be communicated with the (voodoo) server and some other operations can be done in the normal (voodoo-less) fashion. Fourth, since fusion is only meant for IPC, does voodoo make fusion obsolete? Any advice or comments will be appreciated. Regards, M. _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
