Alle 17:21, sabato 14 giugno 2003, Denis Oliver Kropp ha scritto:
> 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.
Surely i think it will have to be reentrant at least, 2 or more
IDirectFBEventBuffer in different threads do not have to conflict ...
Anyway if a 1-thread app can remain a 1-thread app and read directly
/dev/fusion, i think it could also be more responsive then if it have to wait
for the mutex ...
It can be quite complicate, but if 2 IDirectFBEventBuffer in different
threads call WaitEvent, the first could set a mutex and read /dev/fusion, the
second wait for the mutex and wait for the read to finish ...
mmh
>
> > 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 was just meaning that currently if you decide to run 1 process only (ie a
game) it is currently the master, and reads directly the input, with no need
for another process ...
>
> 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.
Ok, more or less what i was just thinking about :-)
Thanx
Maurizio Monge
PS: what about the irc channel?
with xchat i get:
--- Looking up irc.openprojects.net..
--- Unknown host. Maybe you misspelled it?
am i using wrong server?
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
