Improvements to Pimax SLAM tracking.

[mbucchia]

Some proposed "fixes", but really just wonky workarounds.

Pimax SLAM origin doesn't seem consistent across restarting pi_server no matter whether the Pimax Room Setup was run. In order to avoid being a mile high or upside-down, force a recenter upon connection to PVR. This of course doesn't ensure that you will start in the room at the correct position every time, but at least it gets you closer than before.

Also bump up the priority of the tracking thread. This might help with people who've seen stutters (and I guess they probably incorrectly mess around with process lasso or others).

[ethanlessiter]

I confirmed an eye-tracking failure case on Dream Air with Pimax EVO/OpenPort and Sboys beta.1.1. The underlying Pimax/Tobii source stopped advancing pvrEyeTrackingInfo.TimeInSeconds for over 419 seconds.
Sboys continued processing the repeated sample and assigned it a fresh local timestamp, so SteamVR still received the last frozen gaze as current/valid.
Suggested defensive behaviour: track the PVR source timestamp and, if it stops advancing for a short timeout, publish eye tracking as inactive/invalid until a newer source sample arrives. Logging source-stalled and source-recovered events would also help diagnosis.
This would not fix the underlying Pimax/Tobii runtime freeze, but it would prevent stale gaze from being passed to foveated-rendering consumers as live data.

Has anyone else seen this?

[mbucchia]

It's a weird place to have this conversation (open new issue instead?)

I believe the solution could simply be to pass the PVR timestamp to this call:

CustomHeadsetOpenVR/CustomHeadsetOpenVR/src/Helpers/PimaxCommon.cpp

Line 637 in 2e50b25

eyeTrackingOutput.SetEyeTrackingData(leftAngleX, leftAngleY, rightAngleX, rightAngleY);

Then there is logic in the EyeTrackingOutput helper to ignore poses older than 1s.