Hi, Axel Dörfler wrote: > 4) the way how the mouse cursor is currently moved will introduce a > novelty in BeOS: a hanging cursor on load. Yes, I have talked about that with DW. We should collapse mouse moved messages which come from input server. Unfortunately that is not possible ATM because of BPortLink's architecture (at least, that was my impression when I wanted to do that). BMessages from input_server anyone? :-) > 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 You're the kernel expert. What priorities should we have? > 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) :-) app_server has been thought that way. ;-) That's what RootLayer class/thread is for. The 2+ users will share the PC but will not share not even one window. Tracker should support multiple instances for every user(/RootLayer) I guess. Anyway this is something to be talked about. Now? > 9) RootLayer seems to create a new BPortLink for every outgoing Okay, will declare one as a member. bye, Adi.