[haiku-appserver] Re: input issues

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 15 Apr 2005 14:26:09 +0300


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.


Other related posts: