search

NodeOS / NodeOS

Lightweight operating system using Node.js as userspace
http://node-os.com
MIT License
6.93k stars 608 forks source link

mouse support #69

Open piranna opened 9 years ago

piranna commented 9 years ago

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 commented 9 years ago

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

piranna commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 8 years ago

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

piranna commented 8 years ago

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 commented 8 years ago

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