Accessing controller input in Meta Quest system UI overlays from custom Android-based engine?
We are building a custom engine on top of Android (using the SDK and Gradle, not Unity or Unreal) porting our products and targeting Meta Quest devices (Quest 3 specifically) for the 2D System panels / overlays (the floating windows in the Quest home environment): What we want: We need to capture *any form of controller input* (buttons, joystick, scroll) while the apps system UI panels are visible or focused. Key constraints: We are not trying to modify system UI, only observe or intercept input Even partial input (e.g. scroll events, pointer movement, or indirect signals) would be sufficient What we’ve tried: Standard Android input APIs (onKeyDown, onGenericMotionEvent) Checking for MotionEvent sources from controllers Polling input devices directly Combed through the SDK without luck Is there any supported way (SDK, API, or lower-level approach) to access or intercept controller input when system UI overlays are active on Meta Quest? Any guidance on how input routing works between apps and system UI on Quest would be helpful.
MetaXRInteraction missing Ray visuals for ISDKControllers, but ISDKHands working as intended.
I recently upgraded to the version 1.81.0 of MetaXRInteraction on the Oculus Unreal engine fork. Version 5.6.1 And the controller components don't have ray visuals when interacting with menus. The functionality works, I can click, and elements change when hovered, but it's hard to aim. What's weird, is that the ISDKHand components, do have proper ray visuals. (Expect for the right reticle not getting blue when pinching) I am not sure what is broken, or how to get this working. All parameters are defaults. And I only turn off/on the Ray and Grab components (for both ISDK Hands and ISDK Controllers) when the user selects a hand preference in settings using the Set Active function. Video demonstrating the issue. https://drive.google.com/file/d/1GZB-dCXpaxryZP92I9jXAnZO34Lg9WHP/view?usp=sharing Thanks!How to disable controller's auto-sleep?
Hello, I'm working on a project (PCVR) that continually reads coordinates from Quest Pro controllers (integrated cameras), all works fine in my side. My issue is that the controller automatically turns off (auto-sleep) after few minute if no movements detected, so, reading the controller's coordinates breaks. How to disable controller's auto-sleep? Thank you.
DistanceGrabUseInteractable?
Hi, This is definitely a pretty basic question relating to the Meta Interaction SDK for Unity. I've managed to get a HandGrabUseInteractable linked to a HandGrabinteractable via a SecondaryInteractionFilter. However, I also have a DistanceHandGrabInteractable on that object, linked to its own HandGrabUseInteractable linked to the same delegate as the first. When I grab the object without distance grab, my script calls BeginUse, EndUse, and ComputeUseStrength properly. When I grab with distance, it does not, as far as I can tell - I am working on Mac and the simulator was not working with this scenario at all, so I have to port the APK to my quest each time I want to test. That takes away a bit of my debugging capabilities. I thought perhaps this was an issue with having multiple HandGrabUseInteractables, but when I removed the duplicate and made the object only have DistanceHandGrabInteractable and one HandGrabUseInteractable, it still did not work. I also wondered if perhaps HandGrabUseInteractable only supports the HandGrabInteractable, and not other HandGrabInteractables? But peeking at the package code and reading the SecondaryInteractionFilter docs seemed to suggest either HandGrabInteractable or DistanceHandGrabInteractable should work, so long as all references are piped correctly. What am I doing wrong? How can I link my DistanceHandGrabInteractable to a HandGrabUseInteractable? Will I need to make my own DistanceGrabUseInteractable script, perhaps using the existing HandGrabUseInteractable as a base? Thanks for the help
Quest 2 Controller Tracking Degradation
Hi everyone, I’m hoping for some input from experienced Quest 2 users before I make a final decision regarding controller replacement / moving away from meta by upgrading my headset. Over time, my right touch controller (and to a lesser extent the left) has developed noticeable tracking degradation. This wasn’t a sudden failure, it gradually became more apparent during gameplay, particularly in Beat Saber where consistent tracking is important for accuracy and fitness use. I’ve gone through extensive troubleshooting, including: Testing in multiple rooms (including a different property) Controlled lighting conditions (no direct sunlight, no reflective surfaces, no LED interference) Fresh batteries (multiple brands) Re-pairing controllers Cleaning headset cameras and controller rings Guardian reset Full factory reset Testing both standalone and via PCVR The issue persists across all environments. I’ve been in contact with support and understand that, as the device is out of warranty, replacement controllers would need to be purchased through the out-of-warranty program. Investing close to £100 in refurbished replacements, seems very risky and steep, I want to be absolutely certain there isn’t a less obvious cause I’ve overlooked, especially since the root cause hasn’t been conclusively identified as hardware failure. Has anyone experienced gradual tracking degradation like this and successfully resolved it without replacing hardware? I’m particularly interested in: Battery contact or movement issues Less obvious environmental interference Known long-term wear factors Any advanced diagnostics I can try I use my headset primarily for exercise, so reliability is important, but I’d prefer to rule out every possible factor before committing to replacement hardware. Appreciate any constructive suggestions — thank you in advance.
Accessibility Feature Request: Conversation Focus Mode for Ray-Ban Meta Display Glasses
Hi everyone! I’m a Ray-Ban Meta display glasses user who is hard of hearing and wears hearing aids daily. I’d love to see a conversation focus mode added that prioritizes voices directly in front of the wearer and reduces background noise. In busy environments, this would make a big difference for hearing-aid users and others who rely on clearer speech in real time. If this type of accessibility feature is ever developed, I would absolutely love the ability to have it added to my glasses and would be happy to provide feedback or participate in any beta or user-testing opportunities. I’ve also submitted this through support channels, but wanted to share here in case the team is gathering feedback.
