Page 5 of 5

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Posted: 27 Feb 2021, 06:11
by Kamen Rider Blade
Chief Blur Buster, do you think you can convince the USB IF (Implementor Forum) to change the fundamental smallest Temporal Resolution for their Micro-Frames to be < 125 µs Micro-Frame in a future USB revision?

If I'm a betting man, they probably don't care about latency like we do and don't see the urgency or need to make a breaking change to the USB protocol / standard to have their Micro-Frame get smaller than 125 µs.

That's why I made the topic Impending Input Bottle Neck in Wired Communications Protocols (USB)

I'm serious about wanting some of us to resurrect IEEE 1394 (Commonly known as FireWire) and take the existing technology, knowledge, and specs and iterate and improve on it.

Since FireWire was already at 8 kHz for it's main clock and all packets are sent Isochronously & Asynchronously to memory directly within 125 µs, that gives us a chance to work on improving the future versions of the Open Source Spec to what we need with finer Temporal Resolution Packets to be sent.

I'm talking about getting the base packet's "Temporal Resolution" to improve from:
125.0000000 µs
_65.5000000 µs
_31.2500000 µs
_15.6250000 µs
__7.8125000 µs
__3.9062500 µs
__1.9531250 µs
__0.9765625 µs
with each major iteration

And since the last patent on IEEE 1394 has recently expired, I think there is a easier chance to improve on the tech with a open source / open standard group taking over and improving on it.

Kind of like how 3D printing came about from expired Dot Matrix printer patents, we can do something amazing with low latency interfaces.

We can maintain existing backwards compatibility with current FireWire devices & protocols and just move forward on improving the latency.

FireWire S400 had 4 KiB packets every 125 µs
FireWire S800 had 8 KiB packets every 125 µs
We can improve on it with 1600 Mbps speeds use 8 KiB every 65.5 µs
Next iteration can have 3200 Mbps speeds use 8 KiB every 31.25 µs
And so forth.

Yes, bandwidth will improve for the connection, but that isn't the main focus, the main focus is the low latency and continuous stream of packet data to the host and directly to memory in a safe way that can't be abused.

We have more knowledge of the dangers of DMA and how to secure against it, we can use that to improve on the IEEE 1394 protocol and make it better & safe.

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Posted: 27 Feb 2021, 14:09
by Chief Blur Buster
Kamen Rider Blade wrote:
27 Feb 2021, 06:11
Chief Blur Buster, do you think you can convince the USB IF (Implementor Forum) to change the fundamental smallest Temporal Resolution for their Micro-Frames to be < 125 µs Micro-Frame in a future USB revision?
I'd love to, but... I doubt it. I have more pull in the display industry.

Besides, it could make latency jitter worse, especially in high-noise environments. A higher rate can be subject to more temporal disturbances (e.g. traffic contention, packet drops, error correction disruptions), creating a larger chain of dropped samples before it recovers to accurate temporal sampling resolution. Especially since USB has to go over longer cables than the circuit paths of a circuit board and is more prone to jitter/error correction and the need to contend with other USB behaviors.

A probable better approach would be new logic/workflows to make sure that 125us is not latency but simply sampling rate. For example, a sensor read could make it to the computer in far less than 125us provided the sensor readout was read immediately before the 125us frame. Part of this engineering work can be assisted by having sensor-side timestamps.

We have to aim to more easily-achievable standardizations...

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Posted: 28 Feb 2021, 00:10
by Kamen Rider Blade
Chief Blur Buster wrote:
27 Feb 2021, 14:09
Kamen Rider Blade wrote:
27 Feb 2021, 06:11
Chief Blur Buster, do you think you can convince the USB IF (Implementor Forum) to change the fundamental smallest Temporal Resolution for their Micro-Frames to be < 125 µs Micro-Frame in a future USB revision?
I'd love to, but... I doubt it. I have more pull in the display industry.

Besides, it could make latency jitter worse, especially in high-noise environments. A higher rate can be subject to more temporal disturbances (e.g. traffic contention, packet drops, error correction disruptions), creating a larger chain of dropped samples before it recovers to accurate temporal sampling resolution. Especially since USB has to go over longer cables than the circuit paths of a circuit board and is more prone to jitter/error correction and the need to contend with other USB behaviors.

A probable better approach would be new logic/workflows to make sure that 125us is not latency but simply sampling rate. For example, a sensor read could make it to the computer in far less than 125us provided the sensor readout was read immediately before the 125us frame. Part of this engineering work can be assisted by having sensor-side timestamps.

We have to aim to more easily-achievable standardizations...
I'm with you on trying to get more easily achievable standardizations, that's why I'm trying to pursue the IEEE 1394 route since the standard is largely halted and the last patent has been freed from greedy corporate hands.

Like RISC-V and other Open Source / Patent Free / Royalty Free solutions, I'm trying to think outside of the box and come up with a better solution to your problem, especially the temporal resolution issue =D. If that means going the less common route, so be it =D.

Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.


- Robert Frost

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Posted: 06 Mar 2021, 08:14
by axaro1
Is motion sync / synchronization between usb polling and sensor data(synchronizing SPI communication) important in a mouse firmware?

Like for example Overwatch with High Precision Mouse Input enabled which sends all 1000hz inputs to the server in each packet (Ow is a 63hz tick rate so about 16 inputs for each tick and the server calculates where the input was at a specific time instead of only sending the 16th movement data packet).

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Posted: 11 Mar 2021, 21:39
by Sparky
Should probably also include microsecond timestamping of mouse clicks, so you can interpolate a click location between two sensor reports. Or if the most recent click was after the most recent sensor report, extrapolate from the prior velocity.

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Posted: 12 Mar 2021, 09:00
by lyrill
Kamen Rider Blade wrote:
28 Feb 2021, 00:10

Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.


- Robert Frost
you should check out Mick Hannah, the aussie mtbker. he had a quote on his fb banner pic. something like the road that goes to nowhere tend to lead me somewhere. it's on a commuter-ish road bike tho. That's interesting for someone who race downhill for a living.

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Posted: 21 Apr 2021, 16:23
by Kamen Rider Blade
Chief Blur Buster, is there a reason why you don't want to push for nano-second accurate TimeStamps instead of Micro-second accurate?

I do concur that all the TimeStamping and Floating Point Calculations should be done Sensor/Device side and cast into "int" at the very end, that's the correct step to do while maintaining compatibility with existing API's.

The Time Stamp Batch Grouping based on whatever Polling Rate needs to be truly flexible since your Polling Rate can change quite drastically based on user defined polling rates that are non-standard.

Retriving Batches of Time Stamped Mouse data is critical to feed to whatever stack Windows / Linux is using.

Has anybody ever thought of using the Isochronous mode of USB to feed a constant stream of data from the mouse to Windows so that the OS can update the mouse position close to real time? Windows, or whatever OS would only need to process the mouse data in order and just discard any used or extraneous data. Would we need a "Real Time OS" to get the Isochronous aspect done in a timely & consistent manner?

I know Windows CE had a Real Time Kernal when used with the DreamCast.

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Posted: 29 Apr 2021, 18:49
by Chief Blur Buster
Kamen Rider Blade wrote:
21 Apr 2021, 16:23
Chief Blur Buster, is there a reason why you don't want to push for nano-second accurate TimeStamps instead of Micro-second accurate?
I never advocated against nanosecond timestamps. :D

While it is practically overkill, there's no harm in increasing accuracy -- there's no defined upper limit of accuracy, just that microsecond accuracy is the minimum standard.

Many garden variety microcontrollers have a microsecond-accurate CPU counter, which can be conveniently used as the timestamp method. Not all mice will have the luxury of access to a nanosecond-accurate CPU counter (which are rare).

Possibly timestamps could be in double format, or provided as a numerator/denominator format. So there's no fixed accuracy requirement. I should really say "as accurate as the mouse hardware allows for" -- you could go picosecond accurate or femtosecond accurate with whatever path that HD Mouse API goes for. The timestamps definitely won't have a fixed integer format, as my preference is for floating-point timestamps (under the double data type) where possible.

So by itself, it means HD Mouse API futureproofed to nanosecond timestamps, even though those don't exist on most garden-variety microcontrollers found in gaming mice that people can afford. Even mere microsecond timestamps can be viewed as over 100x more accurate than "USB faith" (i.e. prone to USB jitter) utilized by current 8KHz mice.

Re: Potential HD Mouse Extensions API Specification [ETA by 2025]

Posted: 29 Apr 2021, 19:11
by Kamen Rider Blade
Chief Blur Buster wrote:
29 Apr 2021, 18:49
Kamen Rider Blade wrote:
21 Apr 2021, 16:23
Chief Blur Buster, is there a reason why you don't want to push for nano-second accurate TimeStamps instead of Micro-second accurate?
I never advocated against nanosecond timestamps. :D

While it is practically overkill, there's no harm in increasing accuracy -- there's no defined upper limit of accuracy, just that microsecond accuracy is the minimum standard.

Many garden variety microcontrollers have a microsecond-accurate CPU counter, which can be conveniently used as the timestamp method. Not all mice will have the luxury of access to a nanosecond-accurate CPU counter (which are rare).

Possibly timestamps could be in double format, or provided as a numerator/denominator format. So there's no fixed accuracy requirement. I should really say "as accurate as the mouse hardware allows for" -- you could go picosecond accurate or femtosecond accurate with whatever path that HD Mouse API goes for. The timestamps definitely won't have a fixed integer format, as my preference is for floating-point timestamps (under the double data type) where possible.

So by itself, it means HD Mouse API futureproofed to nanosecond timestamps, even though those don't exist on most garden-variety microcontrollers found in gaming mice that people can afford. Even mere microsecond timestamps can be viewed as over 100x more accurate than "USB faith" (i.e. prone to USB jitter) utilized by current 8KHz mice.
Yeah, that's easy to be 125x more accurate when USB literally has their entire MicroFrame structure as the smallest time unit allowed at 125 μs. And I doubt they'll want to change that for "us" given the long and wide history USB already has in place and they aren't likely to care about latency like we do since they'll think we're crazy and that 8 kHz is "Good Enough".

=D