Qt bindings for libusb

I've finally completed the C++ bindings for libusb - what a fun way to spend New Years Eve.

This implementation is layered on top of the C routines - no changes to any of the existing code, so it should be portable to any platform supported by libusb. It relies on Qt - I looked hard at the STL stuff, but Qt was much better, especially for string handling (yep - USB devices return strings in Unicode). I decided to stay with QPtrList for now, despite being told it wasn't likely to last long - it was a better match for my conceptual design.

I'm trying to get it incorporated into libusb, but distributing it as part of kdelibs is a backup plan.

If Qt isn't available at build time, only the C stuff is done - it automatically detects and adjusts. It only errors out if you specifically ask for Qt support (with --with-qt=yes) and it isn't available. I think that the two hardest parts were getting the autoconf/automake parts right, and remembering how to do strings when you've only got a miserable char*.

The API is documented in Doxygen - its up at

I'm not sure why it looks so horrible when rendered.

The patch includes test code that exercises most of the C++ code. This was the first time I'd tried some of the Test Driven Development ideas. Seems to work well - it is very powerful knowing that "make check" is covering my backside when I make changes late at night. The test harness handles Qt bindings being present/absent, and also for tests that only work on Linux. I hope so, anyway.

This isn't supposed to be the final design / implementation - I'm putting this one out for suggestions and testing. I can now get onto the whole point of the exercise though - support for the vendor specific features in Logitech mice.


I just thought I'd make it known that for the last week I've been working on a new KDE application - KHotPlug. It's really a prototype for an idea I had -- a USB device management system for KDE. It uses passive notifications when devices are connected, supports events to be executed when specific devices are connected and a front-end devices amungst other things. It doesn't use libusb, or the Qt bindings because at the time they didn't exist though when I release it out and get some feedback to whether or not it is needed in the community I can consider porting it over.

Just a heads up incase anyone attempts to reinvent the wheel.


By martin galpin at Wed, 12/31/2003 - 13:56

You might want to check out the HAL (Hardware Abstract Layer) proejct on Currently it seems to be a little GNOME-centric, so some KDE input and involvement would be useful before we get stuck with it. ;)

By Navindra Umanee at Wed, 12/31/2003 - 19:50

Yes, why not take a look at HAL? The FAQ explains a lot too.

Furthermore, the following gentoo forum thread indicates that using udev and D-BUS can be quite powerful too. There's already a GNOME D-BUS implemenation working ...

By KDE User at Sat, 01/03/2004 - 00:06

if my memory serves me correctly, someone posted screenshots and working code that did something very similar to what the links in the forum discussion link to... basically allowed setting the default action upon the insertion of various removable media.

btw, D-BUS isn't desktop specific, and KDE will likely be slurping D-BUS into the core libs in KDE4.

By Aaron J. Seigo at Tue, 01/06/2004 - 03:45

I don't see a KDE application for this as a great idea. Major issues include what happens when KDE isn't running (hotplug is used during system setup), and what happens on non-Linux systems.
I do see value in a KDE configuration tool to set up the hotplug scripts, including exec'ing something like kdialog as required.

Guess kdialog needs passive popups!

libusb (with or without Qt bindings) is orthogonal to hotplugging - it is what you use when stuff is already hotplugged.

By brad hards at Thu, 01/01/2004 - 08:08

You're right, the hotplugging system isn't the job of KDE, however I think you misunderstood the application. What I was proposing was a userspace GUI for the hotplug system, obviously only active when KDE is running. In it's simplest form it would provide notification to when devices were connected by monitoring /proc/bus/usb/devices. It would have no impact on "system setup" as you put it because it wouldn't be running. On non-Linux systems, it just wouldn't be installed. I never implied making it part of the KDE base system.

By martin galpin at Fri, 01/02/2004 - 13:44

We could really have some fun. I can just see this being a very handy thing for devices like pen drives, and digital cameras.

Im excited!

By Ian Reinhart Geiser at Wed, 12/31/2003 - 16:32


the firstConfiguration/nextConfiguration stuff looks a bit strange, IMHO it's more Qt'ish
to use Iterators and QValueList in the backend.

Just my 2

By Tobias Koenig at Thu, 01/01/2004 - 03:21

G'day Tobias,

Can you provide a little more detail?

1. should the QValueList hold a pointer to the class or the value of the class?
2. can you show me (or refer me to) an example of how the Interators would be used?

By brad hards at Thu, 01/01/2004 - 08:01