On Jun 11, 2012, at 4:09 AM, Stephen R. van den Berg wrote:
Forgive my ignorance here (perhaps), but as far as I can determine (without actually having written a driver that accesses a HID over USB), the libusb-1.0 interface offered is so generic that it can be used for any USB device, including HIDs.
No, there are per-OS issues surrounding the way HID drivers work, and it's a bit of a mess. libusb doesn't attempt to solve/deal with them, hence the other library(ies). I don't know if there are other limitations beyond HID devices, most of my interests lie in that area.
What would be nice if there were a way to have providers that can be registered and then used (much like the Sql.Provider namespace). If the USB module consisted solely of classes and didn't have any module.pmod magic, one could use join-nodes to blend them together, but then they'd need to be in different module roots.
I'd say there is nothing stopping you from adding USB.HID() or other convenience methods/classes that help you in dealing with HIDs across USB. No need for fancy registering.
If a module exists as USB.so, then there's no way for another module to get mixed in because it can't be physically installed in a sub-location. If USB.pmod were a directory that contained a mix of pike and c level modules, that's a different story, but because classes in c-level modules are housed within a container singleton, it means that the classes in your module couldn't simultaneously follow that pattern _and_ appear in the root of the USB tree. As has been pointed out, it's possible to have the c-level code be in a place holder module (like _USB) and then inherited into the right place via a pike module.pmod, but it still means that any supplementary modules would end up in a module.pmod + dirnode, which sometimes (frequently?) results in odd behavior.
That's the origin of my suggestion that a library glue module not take up the root of a potentially diverse module tree.
Bill