[Nut-upsdev] USB HID - interrupt reports

Charles Lepple clepple at gmail.com
Mon Dec 31 15:23:52 UTC 2007


On Dec 31, 2007 8:26 AM, Arjen de Korte <nut+devel at de-korte.org> wrote:
> 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.

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

> By doing so, at
> the time the interrupt reports are processed the first variable that is
> retreived will trigger a poll for the corresponding feature report and we
> should be fine. The impact on existing bahaviour is limited to one
> additional poll per report received over the interrupt pipeline.
> Effectively, we will only use polling from then on.

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

-- 
- Charles Lepple



More information about the Nut-upsdev mailing list