The Foursquare Blog

For those of you with BlackBerry devices plugged into your Linux machines, you've probably noticed the frustrating fact that no matter what you do, it only asks for 100mA, and then complains that it doesn't have enough power.

And yet in Windows, it all works seamlessly.

Debugging this was a challenge, because I could not seem to find anything special happening on the USB level, when I used either USBSnoop on Windows, or usbfs_snoop on Linux with VMware.

Turns out there was a bug in the usbfs_snoop logging code, which you can fix with this patch (or wait for the next kernel release).

With this patch, the full proprietary USB conversation is exposed, and quickly duplicated for Linux. You can download the juicy results at the Barry project site. Look for bcharge in the SourceForge file downloads section.

Happy New Year!

The last month has been kind of a mental lull for me. Slow progress everywhere.

But alas, I'm finally back on the Barry project after a few months' detour on other critical issues.

The libusb project has undergone an API redesign over the last few months too. It's all in the devel tree. If you're following libusb, and wondering why things are not being updated, make sure you're looking at the SVN repository, not CVS as its website says. :-)

Since Barry depends on the devel tree of libusb, there has been some porting needed in Barry, and some hacking needed on libusb. The last little while I've been reading through the libusb code, and adding libusb_wait(), libusb_poll(), and libusb_abort() support, which are critical if you want to use async calls and still avoid a threading library.

Still lots of work needed in Barry. It will be nice to have a working libusb and test setup again soon.

[Edited to fix broken link]

If you have a BlackBerry, and wish to retrieve data from it on your Linux system, consider paying a visit to the Barry Project page and giving the latest release whirl.

This is of course a very early alpha release, but so far it has the capability to download calendar items, email messages (dates not supported yet), and address book entries. It attempts to convert the address book entries into LDAP LDIF format, and the email into mbox format.

You can also use the command line tool to capture protocol data during database retrieval, in case you wish to lend a hand in the reverse-engineering process.

The library and tool are written in C++. The ultimate goal of this project is to create a fully functional syncing mechanism on Linux. My goal is to have the API easily available in Python, perhaps via SWIG, so GUI folks can use it to integrate with their application of choice; but I haven't gotten that far. People with C++-to-Python experience are extremely welcome right now, even to just give advice on some of the pitfalls to avoid on the C++ side, so when the Python integration time comes, it will be as painless as possible.

I hope to see you on the mailing list if you are interested in this project.

One of the projects currently on the front burner for me is a library and application set for syncing the USB model of the RIM Blackberry handheld on Linux. Net Direct is the company behind this project, with full plans to open source it when it's ready. I may put it on SourceForge early if there is interest, but there's not a lot of code to hack on yet.

The first major task, of course, is to figure out the binary protocol that these devices use. I know about the documentation for the serial protocol at the Cassis project, but unfortunately, the USB protocol isn't the same.

There are rumours that the USB protocol may have been reverse engineered already, but my Google searches come up empty. If anyone knows of such a document, please email me. It would bring this project to fruition much faster.

While I'm on the topic, let me plug two fine USB tools:

• usbsnoop - a Windows filter with source code that intercepts the USB conversation between application and device.

• libusb - an LGPL cross-platform library that lets you work with the low level USB interface in userspace, without developing a kernel driver first.

To all the folks that replied to my previous diary entry, thanks! I apologise for being so busy I couldn't respond in depth as I wanted to.