usbhid-ups: automate fallback defaults for pollonly vs interruptonly

[jimklimov]

It seems that various platforms (variability covering OS, CPU, virtualization, USB hardware, hubs, libusb version and whatnot) fare with different success about interrupt vs polling backed communications. This is something users have to know to tweak if their USB UPS is not supported out of the box, and seems so far there is no known (documented) "science" behind it to predict who would need what.

It would be helpful to improve the current situation with:

• nut-scanner ways to check if it can communicate with the USB UPS by default, or needs further tweaks into suggested configuration;
• usbhid-ups (and other?) drivers to track if they were configured not in a "something-only" mode, and the method they try always fails (e.g. usbhid-ups[3135]: [D2] nut_libusb_get_interrupt: Connection timed out as reported) so try to enable the other method as "the only" for current run-time or until it fails.

Keep an eye out for a possibly related problem of USB driver disconnections after some hours of uptime - maybe the fix for this issue would also help address (detect, reset/reconnect/... fix) that other one.

[jimklimov]

UPDATE: In a way this mirrors the situation of #1309 / #1315 that benefits from adaptive async/sync networking comms.

[jimklimov]

For now, adding a soft variant of this - to post a message in driver log about reconnecting. We currently did not track explicitly if recent interrupt processing had I/O errors, and it can take several retry loops until upsdrv_updateinfo() decides to reconnect:

   4.443853     [D5] send_to_all: SETINFO driver.parameter.pollfreq "30"
   4.445986     [D1] upsdrv_updateinfo...
   4.447386     nut_libusb_get_interrupt: Input/Output Error
   4.449303     [D2] dstate_init: sock \\.\pipe\usbhid-ups-nutdev1 open on handle 0000000000000168
   4.452033     [D5] send_to_all: SETINFO driver.parameter.pollinterval "2"
   4.455017     [D5] send_to_all: SETINFO driver.parameter.synchronous "auto"
   4.457235     [D5] send_to_all: SETINFO device.mfr "EATON"
   4.459150     [D5] send_to_all: SETINFO device.model "Ellipse ECO"
   4.461171     [D5] send_to_all: SETINFO device.serial "000000000"
   4.463199     [D1] upsdrv_updateinfo...
   6.466385     [D1] upsdrv_updateinfo...
   6.468542     [D1] Got to reconnect!

   6.470823     [D4] Closing comm_driver previous handle
   6.473921     [D4] ===================================================================
   6.477119     [D4]  device has been disconnected, try to reconnect
   6.479886     [D4] ===================================================================
   6.484463     [D4] Opening comm_driver ...

[jimklimov]

Update: see also use of disable_interrupt_pipe to customize initialization of certain models of devices supported by apc-hid.c and liebert-hid.c (might help with many CPS woes too, it seems).