I note there are also other ETW providers that can help with other events too, such as the event provider for the DWM, which can tell you exactly when it invoked the GPU's driver's `DxgkDdiSetPointerPosition` function, as well as even the (modern-equivalent-of) vblank point - neat (so there's no need to shell-out for a fancy 1000fps video camera now...) .
I know some users here do run and post ETW traces to investigate these input flag issues, but I don't think anyone's yet used the `Microsoft.Windows.Win32kBase.Input` provider yet, so given the amount of placebo cures and vague, poorly-defined symptoms people claim to be experiencing, methinks if people recorded and posted data like this we'd be in a much better position overall.
----------
Instructions:
- Be running Windows 10 1903 or later.
- Download the 3 files in this repo's subdirectory https://github.com/microsoft/busiotools ... sb/tracing (commit permalink: https://github.com/microsoft/busiotools ... sb/tracing )
- Open an elevated cmd.exe and run either (or both) `BusesTrace.cmd` and/or `usbtrace.cmd` - and in the menus choose USB+HID logging. Note that this will not log/trace DWM events.
- If you're able to, start another trace separately for DWM events, you should be able to do this from `wprui.exe` with the right profile selected.
- Move your mouse such that you can reproduce whatever behaviour-it-is-that-you-don't-like
- Stop the traces
- Start `wpa.exe` and load your now-saved ETL traces (and don't forget to load Symbols!) and look for events under `Microsoft.Windows.Win32kBase.Input`.
- Post a reply to this thread with a screeenshot from WPA and/or relevant data in some copypastable format (i.e. plaintext tabular data (TSV/CSV?) in a preformatted block, I guess?). Important: Do not upload the raw *.etl files because they will very likely contain PII (personally-identifiable-information) about you in them
I'll start with my own:
This is what my trace results look like when my mouse is having a "bad" day (but I've had worse):
I have other traces taken on days when my mouse is feeling better (but still has issues); specifically, on good/"better days" the `CursorRenderLatency` values are significantly better than in that screenshot above.
I still don't have a clue as to the actua underlying cause, and I've been having this problem since late 2019 when this problem started without any obvious cause on a completely different machine - though all my machines have certain common hardware (e.g. Intel Core i7 chips made since 2016, all have ASUS motherboards (but different models) with stock Intel NICs on-board - which are also commonly reported by other people experiencing the same issue.
I'm also wanting to find out if it might be an issue or misconfiguration with USB or HID buffer sizes.
I also shelled-out for a very expensive USB 2.0 protocol analyzer which allowed me to figure out that part of the problem is the host PC waits unnecessarily before issuing USB IN poll requests to the mouse whenever the mouse slows down too much, and that unnecessary wait adds latency - but also that the length of the delay seems to be proportional to the mouse's speed right before it slowed down... or I could be misunderstanding things. Fun.