[Nut-upsdev] USB HID - interrupt reports

[Arjen de Korte]

>> I'm strongly opposed to that changes for *MGE* devices.
>> We would end up in missing some setting changes that are only reported
>> through the interrupt pipe (like when muting the beeper) and overload
>> some old low end units (resulting in temporary DOS when OB).
>
> There may be some merit in your first argument, although so far I have
> never seen an input report that didn't also have a matching feature
> report. Not having that, would mean that if one missed the input report
> (for whatever reason), you'd never know about the change in state and also
> could not poll for the actual status at will (there is no way to tell if
> and when an input report will be sent).

In addition to the above, 'usbhid-ups' doesn't (and neither has it's
predecessor 'newhidups') been able to use variables that *only* have an
input report, but not a matching feature report. The HID-to-NUT mapping
has always explicitly looked for the ITEM_FEATURE flag on the HIDData
elements to map them to NUT variables. And if there is no mapping, the
variable can't be used either. So technically, this isn't a change.

Best regards, Arjen