Soon after I bought my Kinesis Freestyle 2 Keyboard, I noticed that the media keys (next/previous song) did not work with Spotify on OSX. The strange part is that they work just fine on iTunes. I decided to email the Kinesis tech support to see if they had a solution.
Kinesis support was extremely quick to respond and informed me that this was a known problem and was fixed in the latest batch of keyboards. They offered to update the firmware on mine for free, but that required me sending them my keyboard (which is awesome!). I didn’t want to do that, so I figured, If they can update the firmware on this thing, so can I!
I had no knowledge of usb keyboards before I started, so the first thing I did was take the thing apart. (Well, one side of it, where all the controls are.) As usual, there was one extra hidden screw under a “Do Not Remove” tag.
The keyboard itself has a few IC’s. The larger one is a Genesys Logic GL850G, which is a USB Hub. this makes sense, since there are two extra USB ports on the keyboard. The second one is an Alcor Micro AU9410 USB Keyboard Controller. Great, now I know what to look for!
After finding the data sheet for the controller, I started reading. The Alcor Micro guys were nice enough to include an example schematic, which included the pinout for the part. After reading some more, I realized there is an optional external EEPROM that can be used to change the controller’s configuration. This seemed like the perfect place to start probing.
Unfortunately, the EEPROM is not labeled. On the other hand, the controller schematic states that it must be ‘a 24C08 or compatible’ part. Microchip makes one, so I found that data sheet. Time to start probing!
The keyboard designers left a nice 5 pin header unpopulated on the board. After some looking around, here’s the pinout I came up with:
1 - VCC 2 - EEPROM Write Protect 3 - I2C SCL 4 - I2C SDA 5 - GND
I used my Saleae Logic to take a look at what the keyboard does when it’s connected. The first it does after starting is read a whole lot of data from the EEPROM. After looking at the addresses, I noticed it was all the USB descriptor information. Including the device name, manufacturer, etc…
The next thing I tried was pressing on a key to see what happened. Turns out that whenever a key is pressed, the controller reads from the EEPROM every ~9ms or so. The address it reads from corresponds to the row and column on the keyboard. The value it reads is a four byte number. For example, when I press the letter ‘A’, it reads 00 00 04 04. The letter ‘G’ results in 00 00 0A 0A. The ‘next song’ and ‘previous song’ keys had slightly different codes 03 B5 00 40 and 03 B6 00 3E respectively.
I wasn’t sure exactly what these numbers meant, so I started googling around. I ended up looking at the USB HID Usage Tables. In chapter 10, they have the Keyboard/Keypade codes. The letter ‘A’ is mapped to 0x04 and ‘G’ is mapped to 0x0A. Great, now I know what the numbers mean! Or not. Turns out the keyboard codes only go up to 0xE7. The rest (up to 0xFFFF) are reserved…
After some struggling, I ended up on the same document, this time in chapter 15 (Consumer Page). Looks like the ‘Usage ID’ 0xB5 is set for “Scan Next Track”. Perfect! I still don’t know what the rest of the bytes mean, but the 0xB5 means scan next track…
Now that I know what I need to change, I have to figure out how to do it. I took out my BusPirate and connected it to the I2C bus. Once it’s in I2C mode, you can dump the entire EEPROM using “[0xa0 0x00][0xa1 r:1025]”. I had to read an extra byte because the last one kept getting NACKed. Always make sure to backup your EEPROM data before modifying! For the curious, here are my EEPROMs contents:
Now that I have a backup of the data, time to start modifying they keys! But no, it didn’t work. I forgot to pull the write protect line low before attempting to write to the EEPROM. Now it works! As a first experiment, I reprogrammed the next song key with “[0xa6 0xA8 0x00 0x00 0x04 0x04]”. Immediately after, pressing the next song key produced ‘a’ characters. Perfect, now I can modify what any key does. (This could be the source of some nasty pranks… but I won’t go there today.)
So the current media key codes are broken… what should I change them to? I have no idea. I spend a good hour or two searching around, trying to figure out what the ‘correct’ code would be, with no luck. I started thinking about how I could brute force all codes until one worked. Fortunately, I didn’t have to. I went back to the USB HID Usage Tables and noticed the ‘Fast Forward’ and ‘Rewind’ keys, which had codes 0xB3 and 0xB4. Could it be that easy? Nah, there’s other bytes which are different in the current configuration. Lets try it anyway… So I programmed these values on the EEPROM: “[0xa6 0xA8 0x03 0xB3 0x00 0x40][0xa6 0xE0 0x03 0xB4 0x00 0x3E]”
Turns out it was that easy! The media keys work now. :) I have no idea what the last byte does, but changing it didn’t seem to affect the key function. So there you have it. Instead of sending my keyboard back for a firmware update, I spent the morning probing around and fixed it. Much more fun, not to mention educational! If there’s anyone else with this problem, I hope this helps!