XHC WHB04B development?

I tested the errorhandling branch by modifying the requestManaulMode back to the original. Then I can get the dongle to disconnect reliably. While I maybe did not do exhaustive testing, the dongle reconnected successfully every time I generated a disconnect. So at least based on this your code is working as expected.

Also with the original code, the pendant would reconnect for me if I simply removed the assert statement. I know that no "restart" is triggered from that alone. But because the USB device has been disconnected, the libusb_control_transfer will fail just a few moment later, and that will trigger the restart. For Hakan it didn't reconnect, but that was because it segfaulted in libusb. Anyway, now the assert statement is gone and there is some proper handling of the libusb_submit_transfer errors.

While you are there in the setupAsyncTransfer function, the libusb_fill_bulk_transfer() should really be a libusb_fill_interrupt_transfer(). If you do a lsusb -vvv, you see that endpoint 1 IN is really an interrupt endpoint:The bInterval means it should be polled every 2 ms (for a full speed device, as this is). I don't think that is guaranteed by a bulk transfer. And the interrupt transfers should also be given higher priority on the bus than bulk. I'm not saying that using bulk transfer causes issues. But because we have also had disconnect that are in my opinion not related to mode switching, it's at least possible that using interrupt transfers instead of bulk could improve the situation. And it's the right transfer type to use...

Thanks for testing!

There might also have been a bug in libusb. This kind of error handling is always difficult to test when you don't have errors.

I did not go that deep into USB. But your explanation sounds reasonable. I changed it to interrupt. It did not make a difference for me but rather correct than wrong but still working, I pushed a new commit. Feel free to test if you did not test that anyway already.

Note: There are also other usleep() in hal.cc. So they might also give issues. However, fixing that is a lot of effort. I thing it's easier to write it new from scratch using parts of the existing code. But if it works now, that's fine anyway...

Tested the latest changes, and everything works as expected. Thank you!

Yeah. I also grepped for usleep at one point, but didn't really bother trying to figure out if it will cause issues elsewhere. If you go back to some of the first posts, you see I also considered writing a completely new component. Part of the reason for that was to have a state model and avoid these blocking sleep calls. The other part was that I think that the level of abstractions used is bordering on ridiculous for the application. The xhc-hb04.cc component has one order of magnitude less lines of code and does more or less the same thing. But now that you are fixing things, and with my own firmware, I personally don't see a need for a completely new component at this time.