I wonder how high I can push the polling rate on Quest 2 for the controllers.

I know OpenXR runtime can handle at least 240 Hz (this is what CloudXR library polls at, asynchronously, to lower remote controller latency).

The big pain point for using Touch Pro controllers on any PC VR headset, is the need to manually recalibrate each session, dependency on OVR API, running two compositors at the same time on your PC. Ugh

Aruco Markers should solve the alignment problem. Plenty of projects use it:

Isn't aruco tracking imprecise for gaming? Maybe, I guess it depends on the framerate, sensor fusion with IMEs...

With Touch Pro controllers, you don't need aruco for that, just during setup / initialization to auto-calibrate and align the tracking spaces from Quest 2 to X HMD.

One interesting thing I noticed with Monado's Android OpenXR runtime, is that it's shipped as an APK itself, meaning, I guess it runs as either a service or just a DLL or something, not sure. Then your OpenXR app links to it or calls it.

So, the app could even potentially receive + connect automatically to a Quest 2 and get super high polling rate controller data from Touch Pro controllers, even if the Quest 2 itself is bumped after initial calibration, it shouldn't matter because Touch Pros are 100% independent.

I mean, any OpenXR app running on an Android smartphone and linking to a customized Monado OpenXR runtime, could do so without any modifications whatsoever and get full 6DOF, accurate, fast, occlusion free controller poses from a Quest 2 sitting on a shelf, acting as a relay.

You could push the UDP controller data to your PC directly and make virtual SteamVR controllers, or a service or library and bake it into Monado XR runtime running on your PC. Voila, no code needed in your game, full OpenXR native functionality (throw in eye/hand tracking too).