> that is the case for usbhid-ups: the various functions that accept a > TIMEOUT use 4 sec...
That is still incorrect and I want to change that in the not so distant future (time permitting). Unfortunately, that also requires some changes in the hid_ups_walk() function that are not so trivial. Basically, what I would like to do is to send a command, read the reply with a timeout of say about a second. If we have a reply at that time, we process it and send the next request. If we get EAGAIN, we just wait for the next round until a 5 second timer has elapsed since sending the command. > And 1 second can be too short. If you handle the EAGAIN return code properly, it becomes irrelevant. >> The problem here is that none of the subdrivers in 'megatec_usb.c' in >> nut-2.2.1 handle the return codes from the libusb functions properly. By >> sending the EAGAIN error code, they clearly indicate that the command >> needs to be retried, instead of declaring it a failure. This might be >> handled a little better from r1211 onwards, which added a the >> possibility >> to reconnect. I'm not sure if reconnecting is the proper way to handle >> this though. It might be better to just retry the command the next time. > > has this been backported to Testing? I hope not, because there are still a couple of loose ends in the trunk, so I wouldn't consider this code stable enough for Testing. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57
