FreeLists / haiku-appserver / [haiku-appserver] input issues

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

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.