[Nut-upsdev] some megatec-usb issues

[Peter Selinger]

Alexander I. Gordeev wrote:
> 
> Hi All,
> 
> I've finally found solutions for my previous problems.
> But since this includes changes in the shared files, I'd like
> to discuss them here.
> 
> 1. Driver restart problem.
> When I start the driver for the first time, everything is ok. But
> when I want to restart it, problems begin. The driver fails to read
> Report descriptor for the second time (libusb_open is used to open
> the device). This is caused by my particular UPS model's allergy. I
> can read the Report descriptor only once and only before reading any
> "special" string descriptors. After that I can do everything else
> without troubles. But if I attempt to read it after reading string
> descriptors than everything stops working (string descriptors
> too). So I have to reset UPS...
> 
> This works perfectly under Windows, as the Report descriptor is
> retrieved only once - by the OS. Program that drives UPS doesn't do
> it.  So the solution is simple: not to retrieve any HID descriptors
> as I don't need them and they cause problems. But I think the best
> time to determine whether to retrieve HID stuff or not is while
> device matching is performed. There could be other devices and
> subdrivers that need these things. My solution is to reserve some
> value that a matcher can return indicating that we don't need
> HID. For example, 2. I looked through other drivers that use
> libusb_open, and their matchers all return 1. (If I'm not right,
> please, tell me). So this decision wouldn't affect other
> drivers. Also I want to note that any matcher should be able to
> prevent retrieving HID descriptors.

I don't like the idea of returning a different value from the matcher,
because it has nothing to do with matching. A better idea would be to
pass an additional boolean parameter to libusb_open, to determine
whether to read the report descriptor or not.

> 2. "UPS No Ack" problem.
> 
> I also have a solution for the problem of the "UPS No Ack" answers.

This is a driver-internal problem, as it does not require any other
NUT files to be modified. You should implement the solution that works
best for your device, and does not harm to any other devices. I think
it would be reasonable to retry a failed request, say, up to N times,
where N is some preset value (perhaps even user configurable). (You
should not retry it an infinite number of times, because that could
cause the driver to hang.

-- Peter