Forum Discussion
XR_EXT_eye_gaze_interaction support on PC over Link for Quest Pro
Hi, it's been a year now since Quest Pro was released.
I bought mine originally to develop, amongst other things, dynamic foveated rendering in my PC VR game.
Now, I was told previously by johnkearney that Quest Pro over Link only supports XR_FB_eye_tracking_social, which is heavily filtered so the gazes are stable and can be used for gameplay or social stuff (obviously), but that that XR_EXT_eye_gaze_interaction, which isn't supported over Link, would the correct extension to use for dynamic foveated rendering.
It's not exposed through Oculus OpenXR runtime on PC, and it appears will never be at this point. Can we get a confirmation on this either way? Or am I hoping for nothing.
The reason I ask is because I just became aware that Virtual Desktop and a special SteamVR plugin now indeed support the generic XR_EXT_eye_gaze_interaction extension to work over OpenXR, which makes using SteamVR's OpenXR runtime plus Virtual Desktop superior to what Meta provides with your own official OpenXR runtime.
And it doesn't need any developer account either, which is another issue I keep bringing up that doesn't need to exist, at all.
I wish things would improve, but every time try to push the envelope I run into issues.
The problem with Virtual Desktop and SteamVR plugins, is that they do NOT support full body estimation via the XR_FB_body_tracking extension and I ALSO need that for my games.
So, no matter what I do, I'm left with a jigsaw puzzle of restrictions and limitations that are, frankly, unacceptable at any price, let alone 1400$ CAD that I paid my Quest Pro for.
Right now the only way I can use all the features on PC is with hacks like ODS and that frankly is also unacceptable that people have to write workarounds for the runtime not exposing these features on PC.
3 Replies
Update, I was told by the author of the OpenXR Toolkit that his solution to provide generic eye-tracking is simply a wrapper around Meta's OpenXR runtime that provides the social gaze extension only. So the latency would be the same either way. Sigh. As much as supporting generic eye-tracking is better from a compatibility point of view for other games, it makes no difference to me because I support both methods.
I will compare both extensions side-by-side on Quest Pro standalone builds and see if I can see the difference the filtering makes.
Hi. I am recently trying to enable the XR_META_foveation_eye_tracked extension to get the eye gaze location. But even if I implements the things follows the openxr specification, and no error messages generated, I still keep getting zeros. Actually, I got XR_SUCCESS from the return value. I wonder from your information, until now, quest pro still not support for this extension right? Thank you in advance!
Yes! You're absolutely right, I made a mistake, it is indeed the XR_META_foveation_eye_tracked extension that we need for DFR. But it's sadly not available over Link/AirLink, and to be honest, I'm tired of waiting for Meta to do anything about it, and fed up asking for things that never happen but should be 100% included in the expensive "Pro" headset. It's bad enough it wasn't exposed on day 1, but it's over a year later since Quest Pro came out and XR_META_foveation_eye_tracked isn't available over Link/AirLink, so the only option here for us is to simply remove Meta's overly restrictive OpenXR runtime from consideration and use an open source alternative.
Quest Pro has been basically end-of-lifed, from what I can tell, so I'm not holding my breath that anything will change. In fact, I may stop posting on this forum entirely, that's how disappointed I am. At least with open source streaming solutions I won't be held back by any of these arbitrary restrictions that don't exist on standalone builds. I can forward the data to the PC myself. RIP AirLink
