[Nut-upsdev] NUT and libhid

Peter Selinger selinger at mathstat.dal.ca
Mon Aug 6 15:40:04 UTC 2007

Arjen de Korte wrote:
> > I haven't brought this up recently because I don't have time to commit
> > to this sort of redesign at the moment, but it could be useful to
> > merge some of the HID code in NUT with libhid. Accessing PDC HID UPSes
> > was the original target application of libhid, but Arnaud ended up
> > pulling some old libhid code into NUT before it was a proper library.
> If it is reasonably stable now, I'm all for it to replace the existing
> libhid.
> > One of the libhid goals was to make the backend modular, so that we
> > don't have as much of a mess when switching between USB and SHUT.
> > Right now, libhid only uses libusb, but it could also be an interface
> > to SHUT, the OS X HID API, or even Win32.
> That would be a great idea.
> > I would be willing to do a good bit of the porting work necessary to
> > merge the two trees and fix the HID drivers, but as I said, I won't
> > have time to do that right now. Also, I don't want to push this if the
> > other developers don't think the advantages outweigh the
> > disadvantages.
> >
> > Thoughts?
> The only disadvantage I can think of, is that this would probably require
> installation of a separate (libhid, libhid-dev?) package that would be
> managed not directly through the NUT. This might be a slight inconvenience
> to people building everything from source compared to the builtin HID
> solution we have now. On the other hand, we already require several other
> (development) packages, so adding should not be that much of a problem.
> If we indeed do this, I also propose to put some sensible defaults in the
> usbhid-ups code. Currently it looks like many HIDpaths are treated in the
> same by various subdrivers. In that case, it make more sense to follow the
> approach where subdrivers only need to provide the differences, instead of
> all the translation between HID and NUT. By giving the subdriver
> precedence over the usbhid-ups table and allowing to discard/ignore
> HIDpaths, we could trim a lot of duplicated code.

Probably it's a good idea to do this in a separate branch. My
experience with the HID code in NUT is that it's quite complex, and
has diverged considerably from the libhid project. 

Ideally, libhid should be a self-contained library with a
well-designed and well-documented API. Last time I looked at the
libhid project, it still looked like a bit of a hack. How far has it
come along since then? How is the documentation?

-- Peter

More information about the Nut-upsdev mailing list