Manual mouse movement detection false positives

[1j01]

There is a feature for regaining mouse control (pausing the head tracker temporarily) by just moving the mouse normally. You don't want to interrupt head tracking by accident, so there's a threshold of movement before the mouse will take control from the head tracker. However, I'm noticing it pausing randomly, perhaps especially when moving the cursor significantly with my head, on Windows 11.

Possible solutions:

1. Maybe disable the mouse movement detection until the setMouseLocation promise is resolved? Might not work if outstanding promises overlap. If so, there wouldn't be a period of time where the mouse movement detection is enabled, or it would be enabled even though a later request to move the mouse is already in progress, making it sporadic.
2. Maybe store a queue of mouse positions requested, and compare the current mouse position against each point in the queue.
   I think that should be robust. How long should the queue be? Points could be removed when setMouseLocation resolves, if and only if it's guaranteed that getMouseLocation will return the new position at that point. However, a simple time or count limit should be fine.

Also, this could help:

• Might want to use a history of mouse movement, rather than just the latest position, in order to require more travel without requiring significantly higher speed. This would have to be a separate queue of getMouseLocation results, rather than a queue of setMouseLocation requests. Should consider framerate independence, and ideally define the threshold in terms of travel within a period of time. (Should distance be measured in pixels, inches/cm, or screen percentage? probably pixels, to keep it simple.)

Related:

• https://github.com/1j01/tracky-mouse/issues/21
• https://github.com/1j01/tracky-mouse/issues/11

[1j01]

I could simulate latency by adding setTimeout before setMouseLocation to test this. Maybe wrap it in a function, also for tracking the positions requested.

[1j01]

I got this to be robust by comparing the retrieved mouse position to a queue of mouse positions. It now behaves reliably even with await new Promise((resolve) => setTimeout(resolve, Math.random() * 100)); before setMouseLocation.

[1j01]

Some minor notes from when I closed this:

• I can still get a false positive if I hold down the toggle shortcut (F9) to toggle rapidly, and move my head, with artificial random latency enabled... very much an edge case
• There's also these comments that I'm unsure of, and the behavior may have changed part way through working on this:

  const mousePosHistoryDuration = 5000; // in milliseconds; affects time to switch back to camera control after manual mouse movement (although maybe it shouldn't)

  and

  const regainControlForTime = 2000; // in milliseconds, AFTER the mouse hasn't moved for more than mouseMoveRequestHistoryDuration milliseconds (I think)