Thanks to mandatory timestamps for all mouse coordinates (with a strong recommendation that timestamps be sensor-side) -- the proposed HD Mouse Extensions API doesn't care if it's push or poll or even asynchronous (analog-like).griffin1987 wrote: ↑18 Dec 2020, 07:48Would there be a way to reverse everything to use push instead of poll? Like freesync/g-sync kinda does it for monitors.
This could also lead to power savings which could be relevant for mobile users. The mouse would just send movement or clicks when they happen, up to x hz.
I've intentionally made HD Mouse API proposal agnostic on poll/push -- and sensor-side timestamping will help benchmark whether or not push/poll is lagged or not (and force vendors to improve that).
HD Mouse API can use non-USB methods. Imagine connecting a Thunderbolt mouse with DMA permission granted, if it can be done in a secure way, with a sufficiently flexible cable! It's a bit overkill for majority, but that would be sort of the Holy Grail to run at direct dedicated PCI-X performance specs, if the cable is not TOO thick.
Another theoretical idea is GPIO based methods, like turning the mouse cable into a dedicated SPI bus to a special PCIe card in the computer. But we likely won't do that, because it's too specialized and would cost several hundred dollars per retail unit just to pay off the engineering/NRE costs. However, any hobbyist designer could theoretically try doing that, if they're familiar enough with creating a custom mouse driver that presents standard APIs (legacy mouse API and future HD Mouse API) to apps.
However, behind-the-scenes, USB is the standard for mice, and high-rate USB is better done as a poll method for lower lag, since push-based USB is laggier. Polls can be continuous (for stationary mice) or only intermittent (movement + button). The problem with intermittent mode is the lag before the first movement/press when a mouse is dormant. Because of behind-the-scene USB sheninigians such as power management and such. Which is why some mice have a force always-poll (continuous 1000 Hz even with stationary mice).
My view is we're stuck with USB for now, and HD Mouse API can help punch through USB performance issues with sensor-side timestamps and poll aggregation (e.g. 20 KHz raw mouse deltas on just 2KHz poll, at 10 deltas per poll). Overkill for 60 Hz days, but important for future retina refresh rates on ultrafast-GtG displays.
And you can still do some USB workarounds like performance tweaks + dedicated USB card + dedicated PCIe lane to CPU (and Razer just mentioned they're discussing with motherboard vendors about guaranteed-dedicated-chipped USB ports with zero contention with any other buses and PCIe lanes, etc).
Regardless, latency purists can skip that and do 1:1 operation with the best mouse connection available, while smoothness purists can reduce poll rate + add about 0.5ms tapedelay (for multiple-deltas-per-poll aggregation overheads) to get massively better mouse smoothness with a lower pollrate. The aim is to let the user choose, while still being plug-n-play.