Well, I have based my statement on the next observation: when I experemented with compositor client_connection() function, answering non-EOK to compctl, after such answer compctl started to get EHANGUP on subsequent calls to compositor session. So, when I seen that compositor hangs after call to visualizer_enumerate_modes() with arguments which lead to non-EOK answer in vs_enumerate_modes(), I decided that it happens due to visualizer session hangup.
2014-07-07 19:32 GMT+04:00, Martin Decky <[email protected]>: >> I'm not familiar with Helenos IPC yet, but I suppose that when >> vs_enumerate_modes() finds out that there is less links in modes list >> than the function asket to retrieve, the function hangups session >> calling async_answer_0(iid, <with something != EOK>); >> >> If i'm right, then: when compositor whants to discover how many modes >> visualizer has and calls vs_enumerate_modes() in a loop visualizer >> just hangups at some point leaving compositor without output channel. >> >> Such a great design! > > Perhaps I have missed something, but why and how would > vs_enumerate_modes() hang up the session? > > The async_answer_0() hangs up the connection if and only if the argument > is EHANGUP. This is not the case anywhere in vs_enumerate_modes(). > > > M.D. > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel > _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
