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.
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. 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?)... 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... Thanx (and sorry for my english :-) ) Maurizio Monge -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
