Node.js For Linux Joysticks

[Tim Caswell] has been using gamepads and joysticks to demonstrate his node.js hacks for a long time. The thing is, he has been relying on C++ bindings to handle the hardware while trying to herald the praises of node.js. Why not cut out the middle man and write a joystick driver in node.js? It turns out to be so simple anyone can do it.

Granted, this is not a kernel driver. He’s relying on the Linux kernel to recognize the hardware and provide him with the customary /dev/js0 file which he can then work with. As you can see in the snippet above, he’s looping through code in order to constantly read from the hardware. To get this far he dug through the documentation for joystick packets (yay for open source!) to find that each is made of a 32-bit timestamp, a 16-bit value, and two 8-bit numbers identifying the event type and button or axis.

Once he has the packets, it’s off to the races. Each data type is parsed into an appropriate variable which you can use in the logic of your own program. Don’t be nervous, this will make a great weekend project!

13 thoughts on “Node.js For Linux Joysticks

  1. You SHOULDN’T be telling someone that they SHOULD do something one way or the other without providing a reason. Most (95% in my experience) of the time, when someone tells someone else they should be using a different programming language, it is due to their own preference and lack of knowledge in what someone else is already using. There is no reason to use C in a Linux environment if it can be done in another language just as well. Matters of opinion should be stated as such, if it’s not an opinion provide reasons why.

  2. I’m no node.js expert, but are you recursive calling startRead()?

    I see startRead is the callback function for the FS.open() but then startRead is called again inside the anonymous callback for FS.read().

    That should be a loop should it not? Infinite recursive function calls are bad.

  3. I’ve actually been using the input subsystem for years. Event devices (/dev/input/event*) and uinput provide for endless input hacking potential.

    I personally use a module I wrote for Python to do it. I use a native module to do my binary parsing, so that my version of the structure matches exactly, and then Python code to handle all the logic of doing it correctly, especially uinput.

    My code is available on my github account as pyinput.

  4. The last thing in the world that I want is for javascript to be able to touch my hardware. How do I permanently kill it with fire?

    Don’t feel bad, I think the same of WebGL. Too much potential for security shenanigans.

    1. Javascript is just a language (a really, really popular one) and it’s being run in more places than just the browser these days. JS != web, and here it’s being used for a system program just like Python or Java could be.

    1. Circa the y2k apocalypse, I wrote a lunar lander game in .php using netscape as the output device.

      I had a bash script that read joystick positions once per second with cron and wrote a one line text file for x,y and button press.

      I was converting some fortran code to php for 3D to 2D surface display and decided to alter the user’s viewpoint with form submits.

      All of a sudden the function/formula I was plotting started to look like a moon crater and I thought… hey, lunar lander! So I bashed up some inertia/thrusters/damping code, added some labels and off we went.

      It turned out pretty good – 45 fps (sometimes 15, sometimes 90!), and although the display code blocked sometimes (no synch between joystick and displayed results – just like actual flights), it wasn’t bad for a few hours of messing about.

      Netscape had memory leaks, so if you let it run overnight, you’d have to reboot. I admit this is not as cool as javascript quake, but it was fun!

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.