Need help?
<- Back

Comments (29)

  • 2bird3
    Nice article, happen to have been working on a usbip system for my Macbook M3 using similar tech.Worth noting that, this approach is limitted on newer macOS systems: can't build libusb "userspace USB drivers" for devices that are supported by macOS. Without manually disabling some Security features, can't override drivers for system-recognized USB devices.
  • matheusmoreira
    Man I wish I could have read this article years ago. Reverse engineering my laptop's features would have been so much easier. My keyboard LED program is still among my favorite projects.
  • kevmo314
    If you are interested in doing this in golang I wrote a library to avoid needing cgo: https://github.com/kevmo314/go-usbI use this to access UVC devices correspondingly without cgo: https://github.com/kevmo314/go-uvc
  • Neywiny
    But this kinda expects that your USB driver is the application code too, no? This is less of a driver and more of a library + program. If I have, say, a USB to Ethernet device, how do I hook this into the ethernet adapter subsystem?
  • yellowapple
    Perfect timing. I'm expecting to get my hands on a MOTU MIDI Express XT from my local Guitar Center within the next couple days (I paid for it when it arrived there a couple weeks ago, but they have a mandatory waiting period on used equipment to make sure it ain't stolen), which unfortunately uses some weird proprietary protocol instead of class-compliant MIDI-over-USB — so any use over USB from my PCs (nearly all of which are running Linux, OpenBSD, Haiku, or something other than Windows or macOS) is a no-go. This is okay for my immediate use cases (I just need it to route between some synth modules and controllers, without necessarily needing the PC to do any processing in-between), but it'd be cool to get the PC side of things working, too.There's an existing out-of-tree Linux driver¹ that looks promising, but AFAICT it only does the bare minimum of exposing the MIDI ports for use with e.g. JACK, and it's also unclear how stable it is and whether it really does support the XT (the README says the kernel panic got fixed, but there are open issues about it; the README says the XT's supported, but there are open issues about that, too). I'd like to be able to create new routing presets and stuff like what the proprietary companion app can do, and I'd also like to be able to use the thing without needing to shove extra drivers into my kernel, and I'd also like to be able to use the thing on my OpenBSD and Haiku boxen, so I've been perusing LibUSB docs since a userspace USB driver that then presents the relevant MIDI ports and some tooling to reroute the MIDI ports as desired seems like something useful. This article happens to be exactly what I've been looking for w.r.t. a starting point for such a userspace driver.----¹: https://github.com/vampirefrog/motu
  • kabir_daki
    Really useful introduction! Working with low-level hardware APIs is challenging but rewarding. The abstraction layers in modern OS make it easier but understanding what's underneath is invaluable.
  • tosti
    The C++ looks messed up. I have yet to come across a keyboard that can type an arrow.
  • brcmthrowaway
    Dumb question.. do USB devices support DMA? Is it done through the host? Or does the USB device always push/pull data to host memory?
  • brcmthrowaway
    Does the adb tool use libusb or a kernel driver?
  • varispeed
    Ages ago when I was trying to create a simple USB device, I found that there is very much zero information how to do it - e.g. how to correctly write descriptors and so on. The typical advice was: find similar device to what you want to make, copy its descriptors and adapt to your own device using trial and error.Sounds like USB is a wonderful standard. Am I wrong?
  • mjs01
    [dead]
  • webdevver
    [dead]
  • analog31
    >>> Say you’re being handed a USB device and told to write a driver for it.Hand it back, with a request to prove that it can't be done with one of the devices that the OS's already recognize as virtual COM ports.