Jason BARSTOW wrote: > 2. About Fusion. > > Fusion exists to provide support for multiple user processes sharing access > to a single 'directFB runtime'. Is that correct?
Yes. > For a system that expects only a single dfb process to run, or can > virtualise views of the hardware, Fusion is not required? The Fusion library is always used, but the single app version is a pthread based "fake" implementation which doesn't need the kernel API. > When Fusion is used, the first dfb process becomes the Master, and > subsequent dfb processes become Slaves. > > If we consider a system with just two dfb processes running: > What components of each are shared? > - Just the system backend and gfxdriver? All Fusionees are running the same modules, except for the input drivers, which are managed by the master only. > - The dfb core? > - The surface manager? Most core components are shared/run distributed. Search for SHCALLOC and you'll see which control structures are put into shared memory. The code dealing with them is usually shared and is called directly by any DirectFB process (Fusionee). > Do both processes end up with their own mapped views of the video memory? All processes map the frame buffer device (or /dev/mem for example). > Where does the surface management occur? Does the Master provide surface > allocations for both processes? The surface manager code is completely shared. The surface management occurs in any of the processes if necessary. > How does the Slave app get a Lock onto a video surface? Using it's own mapping of the video memory. The lock is acquired running dfb_surface_software_lock() in the slave. > About IDirectFB::SetCooperativeLevel; this describes how multiple DFB > processes interact? (Only one process can go fullscreen or exclusive.) > The dfb process could both have normal cooperative levels, but would then > have their own private primarys? Yes, two windows would appear. In my other recent mail you can read what creating a primary surface using DSCAPS_PRIMARY and CreateSurface() means. You should choose between using IDirectFB's cooperative level with CreateSurface(PRIMARY) and using IDirectFBDisplayLayer and/or IDirectFBWindow. More sophisticated or specific applications don't use DSCAPS_PRIMARY. > If the first dfb process goes fullscreen or exclusive, then the second can > not be run at all? Is that right? It can be run. If it's a window based one, it will operate in the background until the window stack is visible again. If a second exclusive context is created it will put the first one in the background and activate its own, including the whole config. When the second context is destroyed, the first one is activated. If that also goes away, the window stack will be shown if any process has an interface to the shared context, or if windows exist. > Does that mean that two separate dfb processes can never both lock/work > with the same primary? They can use DLSCL_ADMINISTRATIVE to get the shared surface using IDirectFBDisplayLayer::GetSurface(). They can even share windows using IDirectFBDisplayLayer::GetWindow(). Of course, IDirectFBWindow::GetSurface() also works for them. > What about Layer surfaces - Do the two processes have a common view of the > systems layers' surfaces? Yes, they both see the same layer surface with shared/administrative level, but each exclusive context has its own surface. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
