Introduction: Typical VR Controller Compatibility Issues
We have encountered situations where an application that works perfectly on Quest 2 loses functionality on Quest Pro. The cause is different Input Binding Profiles and haptic APIs. Without functional testing of controllers for each headset model, such a bug is guaranteed to make it into release. Our team has conducted over 50 VR testing projects, including shuttle checks on 8 headset models. We perform end-to-end testing—from test bench setup to final report. Bug fix budget savings can reach up to 40% compared to post-release patches.
How to Properly Configure Input Mapping for All Controllers
OpenXR standardizes input via OpenXR Input Binding Profiles. In Unity with XR Interaction Toolkit and OpenXR Plugin, all controller actions are mapped through an InputActionAsset with multiple binding profiles: Oculus Touch Controller Profile, Valve Index Controller Profile, HTC Vive Controller Profile, Windows Mixed Reality Controller Profile.
A common issue: binding is set for only one profile. A developer adds <XRInputBinding path="/user/hand/right/input/trigger/value"> without specifying a profile—the binding applies to the "default" controller and does not work on Index Knuckles or WMR controllers. We recommend using multi-profile bindings: for each action in the InputActionAsset, add bindings for all supported profiles. XR Interaction Toolkit provides a Default Input Actions asset with preconfigured multi-profile bindings—a good starting point, but requires auditing for the specific project.
Specific to Meta Quest Pro: Touch Pro controllers have additional sensors (stylus pointer, face buttons capacitive touch). If the application uses OVRInput directly instead of OpenXR Actions, you must explicitly handle OVRInput.Controller.TouchPro as a separate type—otherwise some buttons return incorrect values. OpenXR Actions are better than OVRInput for cross-platform compatibility: they automatically adapt to the profile, reducing the risk of bugs.
Hand Tracking: An Alternative Input Often Overlooked
Quest 2, 3, and Pro support Hand Tracking without controllers. If the application claims to support hand tracking, it must be tested separately—Hand Tracking has a different input pipeline and different limitations.
The XR Hands Package (com.unity.xr.hands) provides XRHandSubsystem with data on 26 joints per hand. Gestures are implemented via XRHandGesture components or custom logic. The problem: the pinch gesture, the primary interaction method without a controller, suffers from latency and false activations during fast finger movements. In our tests, false pinch activation rates during normal finger activity can reach 15%, which is unacceptable for gaming scenarios. Response latency can be 30–50 ms, critical for rhythm games.
Test cases for Hand Tracking differ from controller ones: we check detection accuracy in low-light conditions (below 100 lux), with hand occlusion, and during fast gestures. We record false activation rates and provide recommendations for sensitivity threshold tuning. Getting a consultation on Hand Tracking setup can significantly reduce debugging time.
Why Haptic Testing Is Critical
Touch Pro and Touch Plus have the TruTouch haptic system—more precise vibration with amplitude and frequency support. Touch on Quest 2 provides basic vibration with a single intensity parameter. The APIs differ: OVRHaptics for native Meta, XRBaseController.SendHapticImpulse(amplitude, duration) for OpenXR. On Touch Pro via Meta XR SDK, OVRInput.SetControllerVibration offers extended parameters. If only the basic OpenXR haptic API is used, TruTouch on Pro controllers will work like ordinary vibration, not leveraging the hardware advantage. As a result, the user loses immersive experience, and the team spends time on post-release fixes.
Test: compare haptics on Quest 2 and Quest 3/Pro for the same game events. Sword strike—different intensity? Expected. Haptics completely missing on one device—bug, we log it.
Test Matrix: What Is Included in the Work
Functional testing is conducted using a matrix: devices × test cases. Minimum matrix for a Quest-first project:
| Test Case | Quest 2 | Quest 3 | Quest Pro | Index |
|---|---|---|---|---|
| Trigger—grab object | ||||
| Grip—hold | ||||
| A/B/X/Y buttons | ||||
| Thumbstick locomotion | ||||
| Haptic feedback on interaction | ||||
| Hand Tracking—pinch select | ||||
| Edge cases (low battery controller) |
Each cell: Pass / Fail / Not Applicable + description on Fail. This is a living document updated with each build. The deliverable is a test matrix with documented Fail cases, priorities, and fix recommendations. Scope includes: Input Mapping audit, haptic and Hand Tracking checks, stress testing of edge conditions.
List of typical controller testing mistakes
- Using only one Input Binding Profile instead of multi-profile
- Missing haptic tests on different models
- Ignoring Hand Tracking in controller scenarios
- Testing only on one device from the lineup
Timelines and Work Format
Functional controller testing requires physical access to devices. If the client does not have test headsets, we discuss using our devices or rental.
| Testing Scope | Estimated Timelines |
|---|---|
| One headset, basic matrix | 2–4 days |
| 2–3 headset models, full matrix | 1–2 weeks |
| Full multi-platform testing | 2–4 weeks |
The deliverable is a test matrix with documented Fail cases, priorities, and fix recommendations. The cost is calculated after receiving the list of supported devices and functionality scope. Get a consultation—we will estimate the scope and timeline for your project.