Hans de Goede

Hi all,

I've been working on getting small digital picture frames to work under Linux. With small digital picture frames I mean 1.1, 1.5, 1.8 and 2.4 inch (often keychain) models, with build in flash memory.

This turns out to be a non trivial task, as all these small devices use custom protocols and custom image compression. It all started with me buying a 1.5 inch 128x128 pixel keychain picture frame for 5 euros for fun. Through googling I quickly learned this frame has an st2205 chipset and also found me this website from people who had already been hacking on this device to use it as a "second monitor" (to display cpu usage stats for example). The person behind this website had already uncovered lots of useful details, such as how to read from / write to the flash on the picture frame.

The picture frame shows up as a 2 MB harddisk through a usb mass storage interface, but you cannot simple read from or write to this disk. Instead a very interesting protocol is used where you communicate with the device by reading / writing sectors at specific magic offsets (sick). This protocol basically allows raw access to the flash chip on the picture frame, for example you need to do separate erase and program commands, and as an erase block is larger then what you program in a single program command you must make sure to always reprogram the entire range the single erase command cleared (and read the entire range before clearing, so you can write it back).

So how to access the device was already known, next step figuring out the image compression. After some failed attempts, I asked help from Bertrik Sikken with reverse engineering the st2205 compression. He went the route of disassembling the windows binaries for uploading pictures, and wrote an algorithm description of the decompression on the picframe wiki.

I used this description to write decompression code. The first version used header files with the lookup tables as C-code arrays and these header files were made by and given to me by Bertrik. I also wrote compression code by "simply" reversing the decompression algorithm. The lookup tables were a problem, as Bertrik copied them out of the windows code, and one could argue that they are copyrightable. Luckily the same tables are also present in the firmware of the picture frame, and we can read them from the frame. So I modified my code to follow this approach to avoid any copyright issues.

So now I had all the necessary ingredients to write software to upload pictures to these devices under Linux. Next question, do I write a standalone app, a library, or extend something existing ? I quickly ruled out a stand alone app, clearly this sort of code belongs in a library so that it can be used by multiple front ends. After some deliberation I came to the conclusion that the best solution was to write a driver (a so called camlib) for libgphoto2, and that is what I've done. My libgphoto2 driver for accessing st2205 based picture frames now is in libgphoto svn. If you have such a picture frame (usb-id 1403:0001) and want to use it under Linux, instructions are here.

As I wanted to have some different models (esp with different display sizes) to test my libgphoto2 driver, I've bought some more keychain picture frames, and of course the second and third and fifth one I bought have different chipsets:

1. usb-id 1908:1315, ax203 with firmware version 3.3.x
2. usb-id 1908:1320, ax203 with firmware version 3.4.x
3. usb-id 1908:0102, ax203 with firmware version 3.5.x

These too have a very interesting protocol to talk to them, and this means that now I'm working on another libgphoto2 driver for these devices, support for the 3.3.x and 3.4.x devices is coming along well. The 3.5.x devices have a nasty image compression algorithm and are currently blocked on that :(

Regards,

Hans