On Mar 13, 2014, at 10:27 AM, Rob Groner wrote: > I think I'm finally starting to get it....If I want this UPS to use just the > generic usbhid-ups driver, then I'm going to have to structure my reports > descriptor to match what it's looking for. Otherwise, I can go off on my own > and structure my reports any way I want...but then I'll have to write my own > NUT driver to look for those specific values (paths). I may end up having to > do that anyway depending on what else we want our UPS to be able to do, but > at this point I don't see why I shouldn't just write our firmware to work > with the usbhid-ups directly.
Well... unfortunately, the difference between "ideal HID PDC UPS implementation" and the products on the market is wide enough that there is currently no "generic usbhid-ups driver": it's more of a generic core, configurable at compile time, with the driver/*-hid.c files defining the special-case mappings between HID path and NUT variables. (In some cases, the mappings even include scale factors to account for misplaced decimal points and other inaccurate values.) >From earlier in the thread: >> To make this UPS as easy to use as possible for the end-user who chooses >> Linux, I figured I would just completely implement the official USB HID UPS >> spec. That way no subdriver would be needed, or at least very little. > > At the moment, we use USB VID and PID to select which HID-to-NUT tables to > consult (since some vendors have "custom" (incorrect) interpretations of > standard HID PDC Usages. So at the very least, you would need a skeleton > usbhid-ups subdriver which matches your VID:PID combination. > > From there, though, if you follow the standard HID PDC Usage IDs, you should > be able to just map the "HID path" (see below) to the corresponding NUT name. Put another way, unless you want to make your UPS bug-compatible with an existing UPS, and "borrow" their USB VID:PID combinations (something I wouldn't recommend, since UPS vendors pay for their USB vendor ID), we would need to add a driver/rtd-hid.c file (or similar) to NUT. It should be very simple, but otherwise the UPS wouldn't work out-of-the-box (until the new subdriver is merged into NUT, and propagates to the Linux distributions). The bright side is that it wouldn't be too hard for you to provide your users patched versions of the NUT source in the mean time. This is something that network card vendors have been doing for years while their drivers get merged into the kernel. I'd like to think we are a bit more friendly and accommodating than most Linux kernel subsystem maintainers :-) At one point, I was thinking the solution should be to make the usbhid-ups core truly generic, and for all but the most difficult cases, patch the HID descriptor before it is parsed. But that would require a lot of regression testing for not a lot of gain (given the difference in frequency of arrival of new UPS models from existing vendors, versus new UPS vendors). -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
