[haiku-appserver] Re: input issues

"DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx> wrote:
> > 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
> Just simply hadn't been done yet. :) Shouldn't be difficult for the 
> initial start. As for restarting it when it's been killed, I'm not so 
> sure about that one.

That's very simple: just let the input_server own the communication 
port. If it crashes, that port goes away, and you can then just (try 
to) start it again.

> > 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
> It shouldn't be, but IIRC Jason Vandermark wrote that code, so I 
> can't 
> say why it was done that way.

I could fix that part, too, it's not that hard 8-)

> > 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)
> That paints an interesting picture. Question: would such a setup have 
> two cursors, then?

That was my intention, yes. Surely, that doesn't have to be an R1 thing 
:-)

> > 7) I can see no reason why LinkMsgReader/Sender are separate from 
> > BPortLink, at least aggregate them instead of doing just another 
> > pointer reference
> I needed to subclass them in order to support sending and reading 
> messages sent over an area. If you have a better solution, I'd be 
> glad 
> to hear it.

Actually, I don't understand this. There is no logic in BPortLink at 
all besides forwarding the requests to either LinkMsgSender or Reader 
(which should probably renamed Receiver to make them a pair).

> > 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)
> Back when I first started working on the server, I thought we should 
> use BMessages all over, but was informed about the performance hit in 
> repeated flattening and unflattening. I'd love to have us migrate to 
> BMessages if we could go to the BMessage format used in Dano/Zeta for 
> R2.

Why do you think should we inherit that performance hit?
I mean we do now as Eric was a bit lazy, but there is no reason it 
stays that way for R1.
But anyway, BPortLink is fine for most of the stuff for now; there is 
no reason to change all that now; input_server communication is a bit 
special as it internally already uses BMessages.

> > 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 :-)
> Not that I've written any code lately, but we all can use a reminder 
> now and then. Thanks. :D

Hehe :-)

Bye,
   Axel.

Other related posts: