Notes on Apple IR remotes reverse-engineering

In 2009, I wrote a driver to make the infra-red remote on my original MacBookAir work out-of-the-box on Linux. The driver was rejected upstream on the basis that the device would soon be supported through more generic means. In the meanwhile, it lived in Fedora's kernel tree, and I took some notes about implementing pairing, so that only your remote would work with your computer.

I'm posting this now because I wanted to poke at a MacOS X application today, and couldn't for the life of me remember the name of the program to monitor disk-activity. Hope this finds its way to a search engine near you.

• Launched the System Preferences, Security, and unlock the panel.
• In a terminal: sudo fs_usage -f filesys -w and check the output when enabling/disabling the remote.
• We can see the modified file is /Library/Preferences/com.apple.driver.AppleIRController.plist
• Installed PlistEditPro and opened the file up.
• Now try to pair a remote (menu and next together)
• You can see the UID value changing in the file. I named the remotes I had available to me:
• New remote: UID = 145 
• Old clean remote: UID = 24
• Old dirty remote: UID = 227 
• After adding some debug to the aforementioned appleir driver, in Linux, I got:
• New remote: appleir: received (5 bytes) 25 87 e0 91 02
• Old clean remote: appleir: received (5 bytes) 25 87 e0 18 03
• Old dirty remote: appleir: received (5 bytes) 25 87 e0 e3 02
• So the 4th byte is the remote's UID.

Now one could implement remote pairing using a sysfs attribute, a udev helper to apply the pairing across reboots, and PolicyKit helper to set and save the paired UID.

This will be left as an exercise to the reader :)

More on remotes and receivers

After receiving a load of new remotes last week, it was only fair I hacked on gnome-lirc-properties and fixed a number of the long-standing bugs, and release gnome-lirc-properties 0.5.0.

So, what happened

Before the 0.5.0 release, we had a very small number of remotes and receivers combination declared, and unless you owned a receiver and remote that the developers did, you had to select your receiver/remote combination by hand.

Johannes Schmid fixed half of that problem by creating a script that'll go through the lirc sources to add all those remotes to our remotes list. I fixed up a number of bugs, added quirks, and support for parsing user-space drivers.

With that, we went from around 10 remotes/receivers combinations to just short of a hundred.

What's next

ir-core work is ongoing in the kernel, and will provide drivers for a number of receivers with a default keymap. That means that things will work as soon as you plug them in.

A number of receivers also already have input drivers, one level down from ir-core, and work out of the box, such as the ati_remote and appleir drivers.

As we can receive events from the remotes, we just need to funnel them to the desktop. That'll be the work of lircd in the short-term, until XKB2 shows up.

Can I help?

Sure you can. Plug in your receiver, launch gnome-lirc-properties and report whether the receiver is not auto-detected, or whether no remote is selected by default. You can also get me one of the listed remotes on this Amazon wishlist :)

My new toys

Thanks to Openismus and Fluendo for sending me 7 new remotes. I guess it means I need to start helping Jarod make all those remotes work using the input layer now :)

Bemused support in Totem

Should have been a one-day quick hack, ended up taking 2 or 3 if I include the research into the (poor) alternatives.

Behold! Totem now includes a plugin allowing it to run as a Bemused server. This means you can connect your phone/PDA/Palm to Totem, and use it to control playback.

First you'll need Totem SVN trunk, and compile with the Bluetooth library headers installed. More importantly, you'll need a client:

• J2ME phones: JamSE (and not bemused.java, see below)
  
• Palm: BTAmp
• Series 60 and UIQ versions available on the Bemused home page

Install the application (left as an exercise to the reader), connect to Totem, and voila! Ready to control.

Now, a comment on the protocol and the code of the different implementations:

• The protocol disagrees with the native Linux implementation (INFOACK, or INF2ACK for INF2 requests? Null-terminated strings, where?)
  
• Doesn't handle Unicode properly, all over the place, the protocol uses NULL characters strings as end of strings, which breaks UTF-8
• More protocol problems, what happens with empty playlists is a mystery
• bemused.java has problems handling empty playlists, and truncates movie titles when not.
• JAMSE isn't open source, and seems hell-bent on using skins, and different clients for different mobile phones ("skin" size)
• The Totem code is horrible, doesn't handle directory listings (the protocol for directory listings is utter shite, and unworkable), leaks all over the place, and is a security risk (seriously).

That said, the competition isn't that great either, as it doesn't even run (although I just notice that my e-mail was actually answered, but didn't get to my inbox). I guess I'll be looking into Remuco soon.