Overclock is unstable with a certain software-hardware combination

[AlexTMjugador]

First of all, thank you for this wonderful USB HID filter driver! AFAIK, this is the only nice way of changing the polling rate of any HID-compliant USB mice on Windows, because for some reason Windows can't expose a nice driver parameter like the Linux usbhid driver does to change this without any hassle or third party software.

After setting up some scheduled tasks to run hidusbf when the system boots, dealt with atsiv to overcome stupid Windows 10 20H2 policies, and configured hidusbf to overclock a cheap USB 2.0 low-speed Logitech mouse that by default negotiates a 10 ms polling interval to 2 ms (i.e. 500 Hz), I was amazed by the results. Tracking was much more smoother, and I could really enjoy what my mouse was seemingly really capable of on both Linux and Windows, the operating systems which I dual boot. What follows is the device information of the USB controller, the USB hub and the USB mice itself as reported by the Windows SDK debugging tool usbview.exe.

Verbose USB devices information

Some strings that follow are in Spanish because that's the regional configuration of my system. However, that probably doesn't matter because you surely know what to look for in those strings or can make sense of them anyway by using something like Google Translate.

USB controller information:

Controladora de host mejorada USB de la familia Chipset Intel(R) serie 6/serie C200 - 1C26


DriverKey: {36fc9e60-c465-11cf-8056-444553540000}\0001
VendorID: 8086
DeviceID: 1C26
SubSysID: 844D1043
Revision: 05

Debug Port Number:  2
Bus.Device.Function (in decimal): 0.29.0

Host Controller Power State Mappings
System State		Host Controller		Root Hub	USB wakeup	Powered
S0 (working)    	D0              	D0              		
S1 (sleep)      	D3              	D2              Yes		Yes
S2 (sleep)      	D? (unspecified)	D3              		
S3 (sleep)      	D3              	D2              Yes		Yes
S4 (Hibernate)  	D3              	D2              Yes		Yes
Last Sleep State	S? (unmapped)   

Root USB hub information:

RootHub


Root Hub: USB#ROOT_HUB20#4&36206eee&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}
Hub Power:                    Self Power
Number of Ports:              2
Power switching:              Ganged
Compound device:              No
Over-current Protection:      Global
High speed capable:           Yes
High speed:                   Yes
Multiple transaction translations capable:                 No
Performs multiple transaction translations simultaneously: No
Hub wakes when device is connected:                        No
Hub is bus powered:           No
Hub is root:                  Yes

Information of the USB hub the mouse is connected to (internal to the motherboard):

[Port1]  :  Generic USB Hub


External Hub: USB#VID_8087&PID_0024#5&355c47ba&0&1#{f18a0e88-c30c-11d0-8815-00a0c906bed8}
Is Port User Connectable:         no
Is Port Debug Capable:            no
Companion Port Number:            0
Companion Hub Symbolic Link Name: 
Protocols Supported:
 USB 1.1:                         yes
 USB 2.0:                         yes
 USB 3.0:                         no

Hub Power:                    Self Power
Hub type:                     USB 2.0 Hub
Number of Ports:              8
Power switching:              Individual
Compound device:              No
Over-current Protection:      Individual

High speed capable:           Yes
High speed:                   Yes
Multiple transaction translations capable:                 No
Performs multiple transaction translations simultaneously: No
Hub wakes when device is connected:                        No
Hub is bus powered:           No
Hub is root:                  No
       ---===>Device Information<===---

ConnectionStatus:                  
Current Config Value:              0x01  -> Device Bus Speed: High (is not SuperSpeed or higher capable)
Device Address:                    0x01
Open Pipes:                           1

          ===>Device Descriptor<===
bLength:                           0x12
bDescriptorType:                   0x01
bcdUSB:                          0x0200
bDeviceClass:                      0x09  -> This is a HUB Device
bDeviceSubClass:                   0x00
bDeviceProtocol:                   0x01
bMaxPacketSize0:                   0x40 = (64) Bytes
idVendor:                        0x8087 = Intel
idProduct:                       0x0024
bcdDevice:                       0x0000
iManufacturer:                     0x00
iProduct:                          0x00
iSerialNumber:                     0x00
bNumConfigurations:                0x01

          ---===>Open Pipes<===---

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0002 = 1 transactions per microframe, 0x02 max bytes
bInterval:                         0x0C

       ---===>Full Configuration Descriptor<===---

          ===>Configuration Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x02
wTotalLength:                    0x0019  -> Validated
bNumInterfaces:                    0x01
bConfigurationValue:               0x01
iConfiguration:                    0x00
bmAttributes:                      0xE0  -> Self Powered
  -> Remote Wakeup
MaxPower:                          0x00 =   0 mA

          ===>Interface Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x04
bInterfaceNumber:                  0x00
bAlternateSetting:                 0x00
bNumEndpoints:                     0x01
bInterfaceClass:                   0x09  -> HUB Interface Class
bInterfaceSubClass:                0x00
bInterfaceProtocol:                0x00
iInterface:                        0x00

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0002 = 1 transactions per microframe, 0x02 max bytes
bInterval:                         0x0C

Cheap unnamed Logitech USB mouse information. This mouse came in a bundle with an also cheap Logitech K120 keyboard. It has no user-friendly model name. Printed in its downside just has some "P/N", which is "810-002182"; "PID", which is "HS511HB"; and "M/N", which is "M-U0026". Some Google results say it is a Logitech M90, and others say it is a M100, though:

[Port2]  :  Dispositivo de entrada USB


Is Port User Connectable:         yes
Is Port Debug Capable:            no
Companion Port Number:            0
Companion Hub Symbolic Link Name: 
Protocols Supported:
 USB 1.1:                         yes
 USB 2.0:                         yes
 USB 3.0:                         no

Device Power State:               PowerDeviceD0

       ---===>Device Information<===---
English product name: "USB Optical Mouse"

ConnectionStatus:                  
Current Config Value:              0x01  -> Device Bus Speed: Low
Device Address:                    0x03
Open Pipes:                           1

          ===>Device Descriptor<===
bLength:                           0x12
bDescriptorType:                   0x01
bcdUSB:                          0x0200
bDeviceClass:                      0x00  -> This is an Interface Class Defined Device
bDeviceSubClass:                   0x00
bDeviceProtocol:                   0x00
bMaxPacketSize0:                   0x08 = (8) Bytes
idVendor:                        0x046D = Logitech Inc.
idProduct:                       0xC077
bcdDevice:                       0x7200
iManufacturer:                     0x01
     English (United States)  "Logitech"
iProduct:                          0x02
     English (United States)  "USB Optical Mouse"
iSerialNumber:                     0x00
bNumConfigurations:                0x01

          ---===>Open Pipes<===---

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0004
bInterval:                         0x02

       ---===>Full Configuration Descriptor<===---

          ===>Configuration Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x02
wTotalLength:                    0x0022  -> Validated
bNumInterfaces:                    0x01
bConfigurationValue:               0x01
iConfiguration:                    0x00
bmAttributes:                      0xA0  -> Bus Powered
  -> Remote Wakeup
MaxPower:                          0x32 = 100 mA

          ===>Interface Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x04
bInterfaceNumber:                  0x00
bAlternateSetting:                 0x00
bNumEndpoints:                     0x01
bInterfaceClass:                   0x03  -> HID Interface Class
bInterfaceSubClass:                0x01
bInterfaceProtocol:                0x02
iInterface:                        0x00

          ===>HID Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x21
bcdHID:                          0x0111
bCountryCode:                      0x00
bNumDescriptors:                   0x01
bDescriptorType:                   0x22 (Report Descriptor)
wDescriptorLength:               0x002E

          ===>Endpoint Descriptor<===
bLength:                           0x07
bDescriptorType:                   0x05
bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
bmAttributes:                      0x03  -> Interrupt Transfer Type
wMaxPacketSize:                  0x0004
bInterval:                         0x0A

Topology of the relevant USB devices:

However, my initial happiness didn't last for too long. I noticed that, on both Linux with the mousepoll driver parameter fixed to a value and Windows with your hidusbf driver, the mouse started disconnecting and reconecting itself seemingly at random. Sometimes it stopped moving for a split second and reconnected itself quickly again, playing the Windows device disconnection sound. Other times it stopped working entirely, without Windows playing any sound, and while doing so it also bringed the whole USB hub down with it, so the keyboard which was connected to it stopped working too (perhaps surprisingly, both the keyboard and mouse received power still, because the keyboard had the numeric lock LED on and the mouse laser was still working). In those cases, to continue using the mouse and keyboard, I had to connect them to a different USB hub (which in my case meant connecting them to a USB 3.0 port or to the front USB panel of my PC case), but the problem persisted if I configured hidusbf to also change the polling rate on those hubs. Sometimes the mouse worked fine for a whole day (8 hours) with no problems, but other times it started glitching out much sooner, in 2 hours or so (it never happened just after turned on the computer, though; the problems always took a while to appear, on both operating systems).

I tried to debug what the heck was happening, and for that I used the Linux dmesg tool and Wireshark USBpcap on Windows. dmesg showed weird messages like this when the hub stopped working:

On Wireshark running under Windows, I was greeted with USB packets like this (I also saw some SYNC_STALL packets at times, suggesting some kind of critical timing failure):

So, with all this information, and taking into account the fact that the problems happen under the USB stacks of both operating systems, I believe that the most probable cause is that something is wrong with the mouse firmware. However, what bothers me is that there seems to be no USB bandwidth limitation, because otherwise the mouse probably wouldn't work at 500 Hz to start with, and that the hardware is really capable of pushing 500 Hz, because tracking is noticeably smoother (Benq Mouse Rate Checker website also confirmed that the mouse was working at 500 Hz), and I don't really want to go back to 125 Hz. What are your thoughts about this situation? Do you believe you can do something about it in your driver, or that I can do something to my mouse to make it behave sanely?

If you need any more information, please don't hesitate to ask. Thank you!

[LordOfMice]

What are your thoughts about this situation?

It's overclocking and sometimes it is NOT possible - as any other overclocking. I have Logitech MX-310 mouse which is literally stop functioning at all when overclocked to 2000Hz (or more) as extreme case.
To your situation (and first two recommendations are obvious, I assume):

1. Check this mouse overclocking on other PC.
2. Check other mouse overclocking on this PC.
3. I know few cases when overclocking was not possible on well-known overclockable devices because they just have bad cable.

Do you believe you can do something about it in your driver?

No, it is hardware problem.

[AlexTMjugador]

I've been testing this mouse in different PCs these weeks and I can indeed confirm that it is something wrong with the mouse. It's a pity, really, but I understand there's nothing you can do about it. I hope that this issue is at least useful to add this mouse to the list of known-broken mices. Thanks for your help!