Nut upsdev - Dec 2007 - USB HID - interrupt reports

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

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57

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

Hi Arjen,

first, best wishes for 2008 to you and your family.

2007/12/31, Arjen de Korte <nut+devel at
de-korte.org>:
> 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. 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.
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).

The best would be to apply your change in libhid.c->HIDGetEvents() if
udev->VendorID is different than MGE_VENDORID

Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems -
http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/