[Nut-upsdev] NUT and libhid

[Arjen de Korte]

> 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.

Best regards, Arjen