GUsb

In colord, I need to do cancellable asynchronous interrupt transfers to talk to spectrophotometer devices like the X-Rite ColorMunki, and connect up libusb1 with a GMainLoop. It turned out Hans de Goede also needed to do the same kind of integration with his spice work. So, we want to share code to minimize bugs as the GSource code gets kinda hairy.

I’ve created a new project GUsb that wraps libusb1 with several high level wrappers that makes it easy to use in GLib programs. See the README for more details.

Go here if you want to look at the pre-release code — although we’ve not yet had a single tarball release yet, and any applications using GUsb have to define G_USB_API_IS_SUBJECT_TO_CHANGE before they can include gusb.h

If you’re interested in helping out please email either Hans or myself. There’s no mailing list just yet. It works for me; If it breaks for you, you get to keep both pieces (or send patches). There are no Fedora or Ubuntu packages at this point, although after the pending 0.1.0 release I’ll submit the package for Fedora package review for F16+.

Note, nothing depends on this library just yet; it’s too late in the GNOME 3.2 cycle to add new low level deps, and it’s also not even slightly API stable. Comments welcome.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

8 thoughts on “GUsb”

    1. Nahh, it’s way too low level. It might make sense to merge this with gudev in the future, but USB is actually quite specialized and well contained, and probably only needed by a handful of processes on the system. You don’t want to bloat the library for everyone else.

    1. No, it’s deliberately there. libusb_claim_interface is currently sync (and fairly slow at that) and I’m hoping to do something clever there (a thread, perhaps). I’m not sure. Ideas welcome.

  3. Good stuff, I was using libusb directly for a usb gadget of mine, maybe I’ll try gusb instead and see if it works out ok.

    A nice glib+gasync+gcancellable example is always welcome.

Comments are closed.