One month before I modified USB overclocking software for work in Win8 - Win10.
First and only fat bug was debugged yesterday
But nothing can stop overclocker. In development process i had seen one feature in code of USB3.0 host controller driver - so it's here: trying to reach polling rates higher than 1000 Hz!
What we need to try?
1. USB3.x host controller
2. Windows 8, 8.1 or 10 (actually we need microsoft driver for USB3.x host controller - USBXHCI.SYS)
3. USB mouse (low/full speed) attached to this controller. Don't mix "controller" and "port" - it's different concepts. You can verify which controller process your mouse in Device Manager, Devices By Connection (device tree) view (qsxcv screenshot from here http://i.imgur.com/wbm0WyX.png):
Do not use USB hubs (for first try), it can restrict rate, attach mouse to controller ports directly. In Device Manager mouse (or HID or composite devices) must be attached to "USB Root Hub" as at screenshot above. Some xHCI controllers like this VIA can have built-in/embedded USB hub for low/full/high speed devices so it's not possible to have 2000+ Hz on such hardware. And some non chipset or this Asmedia controllers are just restricted (hardware bug?) in interrupt rate probably.
How to install:
1. Install HIDUSBF and try to change rate (simply change). If this is successed goto 2
2. Take drivers from 2khz-4khz or 4khz-8khz folders and install it (copy to %systemroot%\system32\drivers\ directly or to the folder of hidusbf setup and then install service).
3. Reboot after 2!
4. Run setup.exe, and try to change rate to 31 or 62. Rate=31 actually equal to 2000 Hz, 62 - 4000 Hz for 2khz-4khz version. Rate=31 actually equal to 4000 Hz, 62 - 8000 Hz for 4khz-8khz version. (Don't forget to restart device.)
5. Check the rate (the best is MouseTester, but you can use dimr, mouserate, MouseMovementRecorder or any other software too). If rate is 31(62) then you done something wrong (new driver installation, USB controller type, newer version of USBXHCI.SYS not known to driver). If rate more than 31(62), but not more then 1000 Hz - you mouse is not capable of HARD overclocking
You can read manual README.2kHz-8kHz.ENG.TXT from jeshuastarr in hidusbf package too.
If anybody can reach actual rate more than 1000 Hz - post your mouse name here.
I personally try this already and my best overclockable mouse (a4tech bw-35) reach 1400 Hz average (unstable).
P.S. Under modern versions of Windows 10 (whether you want hard or ordinary overclocking):
1. If you have problem with driver loading on version x64 1607+ disable Secure Boot or use registry settings.
2. If you have EHCI (USB2.0) Controller only on version x64 1703+ or any controller on version 1803+ use these drivers and (Test Mode or atsiv method with non Test Mode). If you use atsiv then check your AV (or something else like anti-cheat engine) in case you are unable to load atsiv. Or use atsiv and then unload it completely before loading of such engine. And yes, try not to make that mistake.
P.P.S. If you came here for ordinary (1000 Hz-) overclocking drivers and have Windows 7 (or previous version) and Intel chipset with both EHCI and XHCI controllers (i.e. series 7x-9x) then read this manual with this optional addition in case you can not overclock your mouse but still want to use XHCI controller.
Or you can use hidusbfn.zip and one of the two methods described above especially if you have modern Intel hardware with xHCI controller only.
P.P.P.S. JFYI (and for problem troubleshooting): There and following the links you will find the little descriptions of hidusbf internals and there - what it exactly does in system.
P.P.P.P.S. The latest checked system files. If you have files newer then these and can not overclock feel free to send them to me.
First (and main) - if you can not downclock then YOU do something wrong. Without exceptions. And no matter how your files are new.
Second - if you try to overclock device just in the same USB speed interval (for example Full Speed Device from 500 to 1000Hz) then this table is useless for you. There is no problem in software in this case, only hardware.
How to use the table.
1. Find your OS.
2. Find USB controller that controls your device. Use "Copy IDs" in Setup:
"USB\VID_046D&PID_C03E\6&265D47D&0&3" (first line). This is unique internal name (ID) of device. Use it to restart this device only.
Name: USB Input Device
Version: 6.1.7601.24386 (win7sp1_ldr_escrow.190304-1700)
Name: Intel(R) 7 Series/C216 Chipset Family USB Enhanced Host Controller - 1E2D
Version: 6.1.7601.24138 (win7sp1_ldr.180502-0600)
Version: 6.1.7601.24138 (win7sp1_ldr.180502-0600)
or Device Manager if something is wrong with "Copy IDs":
3. Find Driver File name (as above).
You will find two (or even more) driver files in some cases, first is one of USBEHCI.SYS, USBUHCI.SYS or USBOHCI.SYS and second is USBPORT.SYS.
It's normal, we need the second, USBPORT.SYS.
4. Find Driver File version (use "Copy IDs" or Explorer to view property of file):
Then search in table by OS, File Name, and File Version.
If your file is newer then the latest version in the table then send it to me.
Column "HIDUSBFN needed"=Yes means that you have to take files from addition to main package and use Test Mode or atsiv on x64 OSes.
Column "Possible overclocking" describes what kind of overclocking you can have on this hardware and software combination.
LS=Low Speed (max 125 hz), BusSpeed: 0 (in Setup->"Copy IDs")
FS=Full Speed (max 1000 hz), BusSpeed: 1
HS=High Speed (max 8000 hz), BusSpeed: 2
For example on the screenshots i have Windows 10 x64 1903, xHCI host controller, usbxhci.sys Driver File and its version is 10.0.18362.207.
In the table this row is present (10.0.18362.207 falls into 10.0.17134.1-10.0.18362.207 interval) and you have to use HIDUSBFN and can potentially overclock you device up to 8000 Hz.
OS Controller Driver HIDUSBFN Possible
File needed overclocking
98,98SE, usbport.sys, No LS->FS
Vista, 8 (any version)
x86 & x64
8 x86 & x64 usbxhci.sys No LS,FS->HS
7 x86 & x64 usbport.sys No LS->FS
iusb3xhc.sys Yes LS->FS
8.1 x64 usbport.sys No LS->FS
8.1 x86 usbport.sys No LS->FS
usbport.sys Yes LS->FS
8.1 x86 & x64 usbxhci.sys No LS,FS->HS
10 1709- x86 usbport.sys No LS->FS
10 1607- x64 usbport.sys No LS->FS
10 1709- usbxhci.sys No LS,FS->HS
x86 & x64 (10.0.10240.16461
10 x86 1803+ usbport.sys Yes LS->FS
10 x64 1703+ usbport.sys Yes LS->FS
10 x86 1803+ usbxhci.sys Yes LS,FS->HS
10 x64 1803+ usbxhci.sys Yes LS,FS->HS
Marginally less input lag for one thing: On single events like clicking a mouse button USB polling adds latency up to a full poll interval, i. e. up to 1ms at 1kHz, but only 0.25ms at 4kHz; on average 750 / 2 = 375us faster input. Again, marginal.
Additionally a continuous flow of data as you get with standard mouse surface tracking will appear smoother; an update each 250us as opposed to each 1000us means your cursor travel/game rotation is less jumpy. You could also argue a greater polling rate more accurately reproduces the physical tracking path as lower polling introduces a kind of path correction (see Polling Misnomer: https://www.overclock.net/t/1251156/an-overview-of-mouse-technology) as per digital sample rate logic. But as opposed to audio or whatever in mousing the reproduction accuracy for "inbetweens" in constant motion is largely irrelevant; you only really care where you end up at and that's the same for all poll rates. Maybe when you are drawing stuff the visually corrective effect could be annoying, but there you can simply move your mouse more slowly to circumvent this effect. Plus, 1kHz is already "path-accurate" enough anyways - at least I don't think artists are maneuvering their hands consciously on a 1ms-scale.
1kHz is plenty and we don't really need more. This is just interesting fun and play. Near-instantaneous isochronous communication between host and mouse could still be worthwhile in the future, but for that we'd need a dedicated real-time interface with CPU-independent input processing and mice that internally support sending out their data at rates far beyond the USB standard (i. e. after each individual frame correlation step, which is 6000-12000 times per second?).
Yes. Since you get a GUI, polling rate reversion is just a few clicks. Complete reversion works by uninstalling the hidusbf filter driver (right-click HIDUSBFU.inf and hit install) and disabling testmode.
This feature in the code of Windows 8/8.1/10's USBXHCI.SYS, is it possible to find it in other (3.0) controller drivers too?
It's the feature of hardware controller, of couse, but now it can work only with MS drivers. The reason is the same as overclocking of low speed devices now not worked with Windows 7 + USB 3.0 controllers - i can't RE all OEM drivers in the world And yes, direct host controller (outside the driver) programming is possible - but this task is _huge_.