Hi there, I had a look at how the input_server communicates with our app_server, and even though there is only one obvious bug (input_server is not started by the app_server), there are a lot of things done badly, or at least I think so: 1) as I said, the input_server is not yet started by our app_server. This, for example, was the reason why I never got any input; I just didn't know that this part is missing from the app_server 2) the input_server creates a new BPortLink (which is not that cheap after all) for every update message, instead of having a local copy 3) while the RootLayer seems to be where input/output come together, for some strange reason, the display driver (!) must create the input_server listener port, though as far as I understand it, there might even be more than one driver running if we ever want to support real dual head output (which we have to, period) (this, of course, would also cause the need for a special handshake to get the input server port) 4) the way how the mouse cursor is currently moved will introduce a novelty in BeOS: a hanging cursor on load. Instead, we should follow the path R5 has chosen, and use a direct handshake for updating the mouse cursor position only (note, the view transfer messages are still done over the standard message path, only the *visual* position update is not, since that's all that matters for perception). 5) from what I can tell the thread priorities are a bit high overall - real time threads should really only do very little in order to keep the system responsive 6) the input_server should probably have separate "streams" for different devices, although I am not sure if the current architecture allows for this; the input_server should offer what it has, and the app_server should tell the it how to multiplex it into different streams (that way we could support more than one user with separate input devices, which would be nice in combination with dual head) 7) I can see no reason why LinkMsgReader/Sender are separate from BPortLink, at least aggregate them instead of doing just another pointer reference 8) if we had a slightly improved BMessage, it would be potentially faster for input_server communication as BPortLink - the input_server uses BMessages internally, and they often could just be forwarded, instead of, like with BPortLink need to be rebuild every time (right now, though, their speed should be similar, as the BMessage stuff is not that optimized) 9) RootLayer seems to create a new BPortLink for every outgoing message; even if a BPortLink construction currently consists merely of 3 mallocs (LinkMsgReader/Sender + the transfer buffer), this could probably be improved if perfomance becomes an issue 10) also, since it's me, I wanted to take the opportunity to remember you that we have a style guide to adhere to. Michael and Stephan seems to know about it at least :-) I've probably forgotten about something, but that should be enough to get a discussion started :-) I don't want to interrupt you from what you're doing right now, I just want you to keep these things in mind. Except point #1, because that's a bug that shouldn't be. Bye, Axel.