On 4.2.2020 16.57, Alan Stern wrote: > On Tue, 4 Feb 2020, Lauri Jakku wrote: > >> -- v1 ------------------------------------------------------------ >> send, 20ms apart, control messages, if error is timeout. >> >> There is multiple reports of random behaviour of USB HID devices. >> >> I have mouse that acts sometimes quite randomly, I debugged with >> logs others have published that there is HW timeouts that leave >> device in state that it is errorneus. >> >> To fix this I introduced retry mechanism in root of USB HID drivers. >> >> Fix does not slow down operations at all if there is no -ETIMEDOUT >> got from control message sending. If there is one, then sleep 20ms >> and try again. Retry count is 20 witch translates maximium of 400ms >> before giving up. >> >> NOTE: This does not sleep anymore then before, if all is golden. > How do other operating systems handle these problems? Perhaps we > should use the same approach. > > Also, if this problem only affects USB HID devices, why not put the > fix in the usbhid driver rather than the USB core? > > Alan Stern hmm, i investigate, what i know now is few mentions about mouse acting up etc. I do more research, tomorrow. I think in my mind, that the core is good place, the thing ppl are forgetting that it does not make any unnecessary sleeps and when it does it it is about 70-100ms max per loop, and they are restricted to 20. The patch does not enforce any different use, in non-timeout case it is as fast as without the patch. I can easilly debug, cause my mouse acts up and that 5 loop version that I tried on my PC+ usb keyboard + usb mouse. It was way better. And now i got confirmation from my dad (Suse user) that with latest kernel, there have been acting up. The timeout retry loop done in patch within the USB core activates only when the timeout happens, and latest version adapts the 5000ms (common) to 50ms timeout, and sleeps 20ms per loop. But, keep comments coming & suggestions .. and if someone could test too, so I do not be only one to test this :) .. -- Br, Lauri J.