[Nut-upsdev] USB HID - interrupt reports

Arjen de Korte nut+devel at de-korte.org
Mon Dec 31 16:01:04 UTC 2007

>> Since reports received over the interrupt pipeline are a recurring
>> problem
>> for various types of UPS'es, I propose to simply ignore the data we
>> receive there and only flush the respective report buffer.
> This probably should be configurable.

I'm not too sure if I would like this to make this configurable. In order
to prevent the faulty reports to end up in the report buffer at all, we
should do this at a fairly low level in the driver (libhid.c).

> The default action when you read from a HID interface handle in
> Windows is to read from the interrupt IN pipe, if one exists. I
> realize that it may be slightly different for the higher-level HID
> functions that retrieve elements from reports, but interrupt transfers
> are the most efficient way to feed status changes in to the system,
> and I have seen a number of non-UPS devices that don't get the input
> and feature reports correct (since it is a more complicated code path
> on the device).

I do agree with most of the above, with the remark that devices that don't
support reading values from feature reports but only input reports would
never have worked in the first place. A variable that is not available as
feature report, will not be used by the driver, since we don't provide a
HID-to-NUT mapping for it then. So we don't loose anything if we just
ignore the input reports received (except for the report number) and only
refresh the values by reading the feature report once. We even don't have
to flush the report buffer, since that is guaranteed to be stale since the
last quick or full poll. Note that I'm not proposing to ignore the reports
from the interrupt pipeline, we only ignore the data (which will be polled
through a feature report).


> This sounds like a good way to handle it, if we know that the device
> is having issues.

I would like to proactively fix this for all devices. Since it merely adds
one additional poll for existing devices, I don't think this is a high
price to pay. Polls are cheap now that we have a report buffer.

Best regards, Arjen

More information about the Nut-upsdev mailing list