OpenXR Eye Gaze Interaction (XR_EXT_eye_gaze_interaction)¶

Status: established
Last updated: 2026-05-31
Sources: Godot Openxr Eye Gaze Interaction Extension
Tags: [openxr, eye-tracking, gaze-interaction, standard, vr, xr]

Summary¶

XR_EXT_eye_gaze_interaction is the cross-vendor OpenXR extension that exposes a user's combined binocular eye gaze as a 6-DOF pose action. It is the common denominator for eye tracking across game engines: Godot, Unity, and Unreal all expose the same extension, and so share the same baseline capabilities and limitations. The extension provides a single gaze direction and a validity flag at the headset's display frame rate, but no per-eye, pupil, blink, or raw-sample data (Khronos Group, 2026). For applications needing only gaze direction it is sufficient and portable; for research-grade behavioural data it is not.

Body¶

Context¶

This article draws on the Khronos Group's OpenXR specification for XR_EXT_eye_gaze_interaction (Khronos Group, 2026), as relayed through the Godot eye-gaze extension digest. The material is a technical feature description of a cross-vendor standard: what the extension exposes, what it deliberately omits, and which headsets support it. Within this knowledge base it is the foundational article of the eye-tracking-in-game-engines strand — the shared baseline every engine builds on — so Godot Eye Tracking, Unity Eye Tracking, and Unreal Eye Tracking all inherit its capability ceiling, and the physiological signals it omits are what motivate the vendor SDKs covered in Sranipal Sdk. Once the source is established here, the points below state its content directly.

Key Points¶

The extension defines a narrow, portable surface for eye gaze. It exposes one gaze direction as a 6-DOF pose under the interaction profile /interaction_profiles/ext/eye_gaze_interaction, bound to the action path /user/eyes_ext/input/gaze_ext/pose, plus a boolean validity flag signalling whether the gaze pose is currently usable (eyes open, tracker confidence sufficient). Updates arrive at the OpenXR frame rate, typically 72–120 Hz depending on the headset (§ What the Extension Provides). Treating gaze as an input action comparable to a controller pose is what lets it integrate cleanly with each engine's action-map system, with eye gaze registered as a pose action under that interaction profile (§ How It Works in Godot 4).

The capability ceiling is deliberately low, and this shapes every engine's baseline. The extension provides no per-eye (monocular) gaze, pupil dilation, blink detection, fixation/saccade classification, or raw samples at the tracker's native frame rate (§ What the Extension Provides). Any of those data types requires a vendor extension (such as Meta's XR_FB_eye_tracking_social or HTC's XR_HTC_eye_tracker) or a non-OpenXR SDK, which is why the standard is a portability floor rather than a research tool.

Device support is broad but uneven, depending on both the headset hardware and its OpenXR runtime. Among the headsets surveyed, Meta Quest Pro and Quest 3 support the extension through the Meta OpenXR runtime (with a runtime permission prompt), Samsung Galaxy XR supports it via its own runtime, and Varjo XR-4 should support it through the Varjo runtime, although this was untested in Godot at the time of the digest. Quest 2 lacks eye-tracking hardware and cannot support it; Pico 4 Enterprise support was partial due to incomplete permission handling; and Apple Vision Pro and PlayStation VR2 had no usable Godot path (§ Device Support Matrix). Support therefore cannot be assumed from the extension name alone.

For research applications the extension is insufficient on its own. It yields a gaze direction vector at display frame rate, not the fixation, saccade, and pupillometry streams a research-grade tracker produces, so the digest recommends a supplementary data channel — for example a socket bridge to Pupil Labs Neon or a Tobii SDK — running alongside the OpenXR gaze pose (§ Limitations Relevant to Research Use).

Conclusion¶

XR_EXT_eye_gaze_interaction is best read as a common denominator: a portable, vendor-neutral way to obtain combined gaze direction that every surveyed engine can rely on, but capped well below research-grade data. Its limits propagate to every engine that builds on it, and are examined per engine in Godot Eye Tracking, Unity Eye Tracking, and Unreal Eye Tracking.

References¶

Khronos Group (2026) XR_EXT_eye_gaze_interaction — OpenXR Specification. Available at: https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XR_EXT_eye_gaze_interaction (Accessed: 31 May 2026). khronos2026eyegaze

Open Questions¶

Does Varjo XR-4 expose XR_EXT_eye_gaze_interaction reliably through a Godot OpenXR runtime? The digest marks this "should work; untested" (Khronos Group, 2026).
What is the actual permission-handling state on Pico 4 Enterprise, given it is reported as only partial?