[Nut-upsdev] NUT and libhid

[Peter Selinger]

How is the support for interrupt transfers in libhid? That's an area
where a clean interface and abstraction would be very useful. The
library should run a separate thread to collect interrupt transfers,
which can then be polled through the API. (For NUT, there is not point
in receiving interrupt transfers in real time, as there is no way to
"push" them from the driver through upsd to the client). 

-- Peter

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.
> 
> Best regards, Arjen
> 
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>