Quoting Monge Maurizio ([EMAIL PROTECTED]): > > I was trying as experiment to use directfb in wine dlls (the windows > emulator). > As i saw that pthread_create alwais fails (for some reason i did not > investigate), i tried to better understend directfb multiapp internals and i > wrote a hack (that works only for slaves) and need no additional thread.
It would be a good idea to do some further investigation. > By what i understood it seems that every app spawns 1 or more thread, > in the case of the master they do read /dev/mouse, /dev/ttyx, etc and in the > case of the slave /dev/fusion and then they save the events they get in the > process mem (and i suppose the master sends the events it doesn't want to > /dev/fusion), and then the EventBuffers wait for the thread/s and/or read the > messages provided. The master is responsible for: - Open input devices, run threads reading from them, dispatch arriving events via reactor to all attached listeners. - Run bone collector threads for windows, surfaces and palettes. These are core objects with reference counters that get updated even if a process is killed by SIGKILL. > Currently the hack (quite brutal, i have to admit), lets me use directfb in > wine dlls, since it adds reads and selects of /dev/fusion in the > IDirectFBEventBuffer interface and so needs no additional thread. > I also think it not safe if two IDirectFBEventBuffers functions are called > by two threads of the app itself (is it currently?)... In general, interface instances are not supposed to be thread safe, although most methods can be called concurrently. But IDirectFBEventBuffer is supposed to be used by multiple threads and does locking for the event queue. > Why not to have a saparate master instead of making the initialisation all > in the first app? > I could also (maybe, dangerously) run alwais as root to read /dev/ttyx and > give the open fd of /dev/fb to the slaves, maybe something else... > Or more realistically chown /dev/ttyx,/dev/fb and then drop priviledges... > I know that the first app (maybe a games) loses the direct control of the > input, but a separate master could be more suitable for a desktop... What do you mean by "direct control"? I'm thinking about some kind of DirectFB display manager (dfbdm?). This would run as root and display a login screen like xdm, after logging in it adjusts the permissions of /dev/fb/X and /dev/fusion/X and spawns the user specific session manager with the user's priviledges. When the session is over it resets the device permissions and shows the login again. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
