When my friend asked me to help him build a CarPC, we decided that the main method of control would be the keyboard, using as few keys as possible. We also decided on the excellent XBMC media player.
The reasons for this were simple, it had an excellent GUI, supported all the major protocols (+UPNP), was extensible using Python (which we both know to a level), was familiar to us (we've been using it for years, I personally got an XBOX just to use it) and could be used perfectly well with a few keys, like on a remote (after all, it was designed to be used in the living room, using a standard remote).
As such it seemed like the ideal candidate, and indeed it was. After building the CarPC and integrating a simple numerical keypad as the interface (with buttons rebinded to what we needed them to do) we found that all that was needed to control the entire system was 15 keys!
This was an excellent system, and was used a lot. When my friend decided to add a wireless AP to his car, then things got interesting.
We could directly talk to XBMC via TCP. This meant that anyone could control XBMC, even when it didn't have focus. This is good because:
I had the perfect device to act as a remote, a Nokia n810. A most excellent device that I just can't get enough of. Excellent in so many ways!
In a nutshell, the n810 is a small arm-based computer running a version of Debian Linux. It has built in support for python, and GUI writing using either the enlightenment EFL libraries or GTK2.
So I set down with python and started coding for the n810, using glade as my GUI designer.
Accessing the basic XBMC functions was easy, as XBMC provided a HTTP-based API you could use to send simple commands.
This was good for the basics, but we wanted to have total mimicry of the keypad, so a second connection was created, which looked like this:
---------------------- ------ | PC ----------- | | n810 | --------[KEY]--------|------| keyserver | | ------ | ----------- | | | | | | | ----------- | -------[HTTP API]----------|--| XBMC | | | ----------- | ----------------------
The idea behind this is that the HTTP API is for the basic stuff, while the second TCP connection sends keypresses to the keyserver on the PC, which then sends the corresponding keypresses to the system.
The nice thing about this system is that it mimics the keyboard, as if you actually physically pressed the key.
The downside to this is that we need to write our own socket server to receive and process these commands.
The code itself is split in two. One python module where all the functions occur, and the GUI part. This is done so you can easily change GUI's, or use the module for automation.
After a couple of hours of coding, the first working version was put to use in the car. As time wore on the system was refined, and proved itself capable of the task.
Thing is, it kind of spoiled me. I like the fact that you could use the remote no matter where you were, as long as you were connected to the network. No need to make sure it's line of sight, or even in the same room.
When I set up my new XBMC system, I wanted to use this same wifi remote. The system was further refined, including the ability to receive information from XBMC.
The main reason for that is so that the system can be used headless. For example when listening to music, I don't want my entire TV running just so I can switch between songs.
So currently, the software works well and can be used on a day to day basis with no issues for me. It's stable, but at the moment released as "works for me", due to the fact only I and my friend use this code. If this interests more people we can make it a proper open-source project. Part of the reason I've written this article is to see if this would be of use to anyone else.
Anyway, here is a screenshot. This is how the latest GTK version looks like:
The keys on the right mimic the keypad from the original car. The "LeftS" and "RightS" buttons on the top are a leftover from the CarPC system (it would switch desktops). The rest of the buttons should be explanetory.
The "X" button was added to allow a way to exit the program (being full screen it didn't have the usual window manager decorations).
The left side is devoted to the info panel, which fetches information about the currently playing item, and the progress bar (currently not implemented) which would give you a percentage value of how much of the item you've watched/listened to.
As you can see, there is still work to be done. The code that has been written is stable, but there are sections that still need to be done. Also, some of the car-specific things can be removed, or redefined for other uses (as 99% of people won't need them).
So, anyone think this is useful? If you're interested email me, and I can put the code up. If you're interested in helping with development also let me know, so we can set up a proper svn repo and project page.
Initial article creation. I'm tired, so might have made some typo's. Now to see if this interests anyone...