[Nut-upsdev] Supporting APC 5G UPSs

Arnaud Quette aquette.dev at gmail.com
Fri Jun 25 19:37:28 UTC 2010

2010/6/25 Arjen de Korte <nut+devel at de-korte.org <nut%2Bdevel at de-korte.org>>

> Citeren Arnaud Quette <aquette.dev at gmail.com>:
>  The 'pollonly' is a flag, so just listing 'pollonly' here would be enough
>>> (the '= 1' part is not used). Assuming this is important for this device,
>>> we
>>> should probably automatically disable the interrupt pipe, so this is what
>>> the revised patch will do upon detecting a 5G UPS.
>> I came to the same conclusion. now to set "use_interrupt_pipe = FALSE;",
>> the
>> content of r1853 should be moved to upsdrv_initups(), before the claim()
>> calls.
> That would be neat, to remove the nag warning when we shut it down. Other
> than that, it will probably be fine as it is now, since the fun pointer will
> be called whenever a 5G APC UPS is detected.
>  and the new apc-hid->usb_device_id_t entry (from Chris' patch) should have
>> a
>> fun pointer to set it.
>> though that last one was obvious!
> Yes. It does however raise the question whether or not we should default to
> using the interrupt pipe (instead of defaulting NOT to use it). The
> interrupt pipe is broken for quite a few popular vendors and models and
> unless you override the default pollinterval, won't significantly reduce the
> latency.
> Using the interrupt pipe is probably most useful for devices where we know
> it is used by the UPS (and implemented correctly) and we want to lower the
> load the usbhid-ups driver presents by increasing 'pollinterval' to
> something like 30 seconds or so. In that case the interrupt pipe will then
> provide you with the near instantaneous response to critical events.
> Any thoughts?

agreed. And the differential polling mechanism does well at detecting major
note that we can get rid of the fun() definitions and put the general case
(use_interrupt_pipe = TRUE) directly in the claim() function.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20100625/c34e52e5/attachment.htm>

More information about the Nut-upsdev mailing list