This DKMS module allows you to overclock some USB devices by overriding their endpoints' bInterval values in the device descriptors – if the device physically allows you to poll it at higher frequency and will give you more data.
Back on Windows this (with the same method) was rather trivial using the "hidusbf" program. And ever since moving to Linux I was pretty annoyed I didn't have a similarly simple enough way of doing the same thing. So basically I guess I had no choice but to make one.
And the module allows doing that for theoretically any USB device without patching and re-compiling the kernel. Installation instructions are in the README (there's .deb, .rpm and AUR packages):
https://github.com/p0358/usb_oc-dkms
So let me know what you think, and if you managed to overclock any gamepads or other devices, or want to try.
It's always great to see someone scratch their own itch, so kudos. However, I'm curious what the actual pain point is? Does your mouse not sample fast enough? Noticeable input lag on a gamepad? Seems like this would be a bug with the implementation if it needs to be overclocked to fix...
Well, it's not that there's a particular "problem" in a sense like a bug. But it's that if the device can be pushed further, and thus by higher polling we achieve lower effective input latency and slightly smoother input, then why wouldn't we do it? The same way gamers get higher refresh rate screens (and sometimes yet try to push them further), or other devices.
As for the implementation, my module is partially based on a patchset for actual kernel module, but it's unclear to me if it was tried to be upstreamed or why it failed if so. But it clearly didn't make it in, and there's no sign of that changing any time soon. Maybe the kernel devs would consider it "unorthodox" to alter the descriptor parameters against what the manufacturer intended.
But some devices do allow themselves to be polled higher and will just sample the inputs more often, if their firmware and sensors are capable of it. In fact, many "gaming" mice have a proprietary software that uses a proprietary protocol (this often has a Linux equivalent like Sonaar for Logitech) to set on-device settings where it'll reconnect reporting different bInterval (requested polling rate) to the host based on what was set. And yet the manufacturers will by default use some "safe default" setting like 125 or 250 at most, just to avoid any potential issues on some devices and thus RMA costs, with opt-in options of 500 and 1000. But some manufacturers don't bother making such an option or an app at all, so that's where this module comes in. And especially for controllers, it's much less common to see such an option even if the app is there, even though high amount of non-Microsoft controllers do allow such overclocking (Microsoft ones at 125 Hz locked are pathetic, you can feel the latency difference between that and my 250 Hz controller overclocked to 500 Hz side-by-side).
But TL;DR is that it's just a gamer optimization, and one that isn't quite easily possible with upstream kernel currently. Some kernel modules do have some options for some degree of overclocking, but e.g. one of them has a bug that it didn't work with USB 3 devices, so yeah...