mouse support

[piranna]

Seems to be fairly easy to read the mouse data and a funny project implement the protocol... :-)

https://github.com/telmich/gpm/blob/master/src/gpm2/mice/ps2.c
http://www.computer-engineering.org/ps2mouse/

Also seems now with USB there will be no more protocols, so this is mostly a one-shoot task. Only point is, should this generate ansi-codes on a terminal, w3c mouse events, or this ones should be generated by a higher library (and by the way, keyboard events, too)?

[piranna]

Ok, this gist is fairly more interesting... ;-)

[piranna]

I have been banging my head and seems I start to understand how it works.

According to http://linux.die.net/man/4/console_codes, linux console is capable to emit mouse reports on the stdin stream, so applications like slap could work, so there's no problems here. Point is, linux console doesn't know about the mouse device or its protocol, so needs something that generate the console terminal ioctls (what? :-/) so the console can emit the reports. But how could this be done? This is the first time I've heard about this... :-(

Also, all mouse devices can only be read by root. This is not so bad, since the mouse could be used only on the local consoles, so it makes sense to have a global service... Only point, do it in Node.js as it should be, or take a shortcut and use the real gpm and forget of problems about create a clone?

[piranna]

Posible solution: since process.stdin is a Stream object, it has a 'data' event, so a process would be able to emit event to it. If so, it would be only to it's child process or to anybody listening to the same stdin stream, so that ANSI codes would be exchanged from one background gpm-like process to the other ones, and would also allow to listen to a particular mouse device for each user.

[piranna]

Ok, process.stdin is a Readable stream and can't be able to write to it, so we can't be able to inject mouse ANSI codes to everybody listening to the same stdin stream. Another alternative is to work as a "filter", piping process.stdin to process.stdout, but also writting there the mouse ANSI codes. In this case, being the first process where all the other ones start on an interactive session, candidates to inject this data are

1. bin-getty
2. logon
3. nsh

bin-getty manage the console as an all, but don't know anything about users preferences, and would only allow to access to a "global" mouse. nsh is run as a user and would allow to change device online, but would make it only available to process started to them.

On the other hand, logon can access to the user preferences (it's already done to know what shell to start) so user would set what mouse to use and will be available for all process and shell interpreters. Problem are that mouse couldn't be possible to be changed online (users don't have access to the logon instance) could be problems when using it as access authenticator for online services like web or wss (we would need to detect that to don't enable the mouse functionality).

[mitsukaki]

It must get boring talking to yourself. Good thing I'm on summer break now! Status update?

[piranna]

Untested, but definitely feasable since we have access to the /dev filesystem, it only keeps to read the interface and parse the mouse events. It would be a funny project :-) Later it keeps to inject the ANSI codes in the terminal input stream as I put in my last post.

[mitsukaki]

Ah okay excellent! I'll get to playing with it in my normal set up and see what I get