Writing Python Drivers For Input Devices

[Stealth] put together a post explaining how he writes drivers for input peripherals. He’s using Python which makes the process fairly painless (we’ll get to that in a minute) but the value of his post is in the explanation surrounding how to interpret the data. Once you know how the communications are coming in from a device you can write the driver using any language you want. [Stealth] wrote in to let us know about this post after reading the PlayStation 3 Sixaxis controller sniffing hack. He’s pretty much doing the same thing but the background information is much more bountiful.

There are a couple of prerequisites to the process. First, [Stealth] is working in a Linux environment. That’s not to say you couldn’t do this on another OS, but you’re going to need to do some research to find out how to tap into the data stream from the device. Secondly, the input you are working with must already be set up and working on the machine. That means if there isn’t any support at all for the peripheral (in this case a USB joystick) you’re not going to be able to sniff the commands. That being said, a short Python snippet is all you need to dump the raw data coming in from the device. With data in hand it’s time to do some pattern hunting. As you start to figure out the size and scope of the incoming packets you can try out your own code to make sure you’ve got it right. Check out the demo video after the break which features a joystick button mapper written in Python.

[youtube=http://www.youtube.com/watch?v=WYaSHPWjU_E&w=470]

9 thoughts on “Writing Python Drivers For Input Devices

  1. I built one of those for a tv remote, but it looks like I used struct.unpack to unpack the buttons into integers rather than reading them as characters. Pretty cool, I’ve not seen very many other examples of Python drivers.

    1. In Windows at least, there are both user-mode and kernel-mode drivers — just because it doesn’t touch the kernel doesn’t mean it isn’t a driver! I’d imagine it would be the same for *nix systems too — there are aspects of a driver that do need the nitty-gritty OS to do the dirty work (Kernel), but then you just need to do some parsing, formatting, etc. that can be done anywhere (User space).

      Always good practice to separate the two, you don’t want to throw bugs into the kernel-side of things!

  2. We are not able to recieve patient’s record lab test result done by machine data from the Cobas c311 blood test biochemistry Analyzer (Following ASTM Protocal ) to seperate host machine(pc )using rs232 port .I thing we require one driver program for reading ASTM message coming from analyzer. Now the problem is just to dump the complete ASTM messages (from the Analyser to host) in a single file , ‘automatically’ i.e without user intervention. From that file we can extract out necessary information.

    1) Setting the serial port parameters i.e baud rate,parity,stop bits etc.
    2) Wait for the data to come, receive it and dump it in a file in real time.

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.