[haiku-appserver] Re: input issues

Adi Oanca <adioanca@xxxxxxxxxxxxxx> 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? :-)

Actually, I was talking about a whole different approach (see Stephan's 
mail).

> > 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?

Well, we'll see; it's hard to say before you actually have the thing 
running. But anyway, I think most display related stuff is not good 
real-time material. Reading buffers out of hardware is; there you have 
real time constraints to consider.
The display should just feel responsive, and you don't need real time 
for that. A real-time operating system is not a desktop operating 
system. You can easily feel that when trying out QNX :-)

> > 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.

Still, I find it very odd, that the display driver creates the listener 
port when it has nothing to do with the communication at all.

>       Anyway this is something to be talked about. Now?

No, not really, depends on how far we get with this before R1. That 
kind of features would make our R1 definitely more interesting for 
current R5 and Zeta users, though.

> > 9) RootLayer seems to create a new BPortLink for every outgoing 
>       Okay, will declare one as a member.

As it's single threaded AFAICT, that should be the way to go :-)

Bye,
   Axel.

Other related posts: