Not too long ago I explained why the Xbox One gamepad is one of the greatest gamepads available right now - and I alluded to the fact that it works very nicely with the xow driver when using the USB dongle to connect to the gamepad (which has less latency compared to using the Bluetooth mode):

However, I did notice, like many others, that the xow driver was actually eating up CPU resources like crazy, to the point it would make your games stutter if you used it when playing any sligthly intensive game. You would also notice that the USB dongle would get very, very hot, fairly quickly.

This can be seen very obviously when running htop once a gamepad is connected:

Turns out xow itself is not directly the culprit, rather the libusb 1.0.24 version. It used to worked fine until 1.0.23, and then this happened:

xow reads USB packets from the dongle using libusb_bulk_transfer. This function submits a USB transfer and calls usbi_wait_for_events to wait for the transfer to complete. When a certain timeout is reached (1 second in xow’s case), usbi_wait_for_events will return. This worked fine in libusb v1.0.23. This behavior changed in libusb v1.0.24. usbi_wait_for_events doesn’t respect the timeout anymore and instead returns immediately even if no event is available. This causes a high CPU usage.

There were several workarounds if you had the issue:

• downgrade to libusb 1.0.23 if you could
• upgrade to a development version of libusb if you were on a rolling distro such as Arch with the AUR
• get a static version of the library and run xow with a LD_LIBRARY_PATH statement
• build the library from source and overwrite your own distro’s version

All, not ideal for users who actually had no idea where the issue actually came from. Now, the problem should be fixed for most people, as the newer libusb 1.0.25 was released officially on Feb 1st 2022 and is now trickling down to several distros following the rollout by maintainers. I just got the upgrade last week on Solus for example, and now xow works exactly like it should with no visible CPU usage.

This is however a great example of how some totally unrelated update can mess up with a perfectly working piece of software until then. And in this case, the fix was NOT fast to come: the 1.0.24 version was from Dec 11, 2020, and the 1.0.25 version came last month. We’re talking about a year of most users being stuck on a libusb version that caused problems for xow.

Now, I wonder what is the good solution for such kind of issues. Some of you may be jumping on the Flatpak bandwagon to say that this would never have happened in the case of a Flatpak archive, but I wonder: Flatpak also prevents duplication of libraries by sharing some common parts across Flatpaks, and libusb could have been impacted just the same as a shared library, unknowingly.

In any case, problem solved, and you can now go back to using the excellent Xbox One gamepad.