cancel
Showing results for 
Search instead for 
Did you mean: 

grip button no longer works with v46

The grip button no longers work for my OpenXR based app with the v46 update.

 

37 REPLIES 37

input/squeeze/click is not a specified binding option for the touch (pro) interaction profiles in the core spec (or FB unpublished extensions) so no. However I do bind both scalar and boolean actions to input/squeeze/value, the latter is equivalent to input/squeeze/click, this is completely a valid things to do in OpenXR (check the spec) and has worked on the Quest OpenXR runtime in the past (and still working on the Oculus PC OpenXR runtime). I have already tried disabling bindings for either scalar and boolean actions still the same.

 

My code for suggested bindings is here the code that uses/manages interaction profiles is here

I already log the current (or switched too) profile, when controllers are active the binding is touch controllers, when hand tracking is active the new interaction profile is XR_MSFT_hand_interaction, which I do have suggested bindings for too and looks like has only been added to Oculus Quest/PC OpenXR runtimes since v46 but not documentated anywhere.

 

You can find the relevant code dealing with interaction profiles in my last post here

Yes, you're correct, both boolean and float bindings to /value is a valid thing that's supported by the spec.

Thanks for your quick responses, it really helps us narrow this down. Some more questions that would be helpful:

What is the exact observed behavior? It sounds like you're just seeing the float action returning 0.0 and the boolean actions returning XR_FALSE?

What are you seeing for the other values returned from xrGetActionState*()? By that I mean: isActive,  changedSinceLastSync, and lastChangeTime.

Thanks,
Andreas

"What is the exact observed behavior? It sounds like you're just seeing the float action returning 0.0 and the

boolean actions returning XR_FALSE?"

 

With either or both enabled, the results of XrActionStateFloat/Bool is always:

changedSinceLastSync: XR_FALSE currentState: 0.0 isActive: XR_TRUE,

 

With lastChangeTime property, the timestamp is some fixed value that never changes, sometimes on start-up it will constantly change until the action set changes and then it becomes fixed and never changing.

 

"What are you seeing for the other values returned from xrGetActionState*()? By that I mean: isActive,  changedSinceLastSync, and lastChangeTime."

 

All other suggested bindings (includes scalar/bool paths & actions) result are completely normal and working, I tested with bindings for "trigger/value", the currentState changes as expected as does the lastChangeTime when the trigger button is pressed & depressed.

 

I even tried disabling all other suggested bindings and only have a single binding for "select/value" bound to a float action and it is still not working.

 

If it makes any difference the input polling happens on a different thread from the main/render thread which also checks for session state changes, but as I have stated before, this was working fine for quite sometime before the v46 update and all other suggested bindings are working.

 

 

@lionleafAny news on this?

We are still trying and failing to reproduce what you're seeing. We will continue to try.

@koujakuis this still a problem that happens with StereoKit?

@jumblistill the same for you?

Yes, this is still an issue.

@VoodooUomo, @lionleaf if it will helps, you can find the open source code for StereoKit at: https://github.com/StereoKit/StereoKit

jenszier
Honored Guest

Any updates on this? One would think that it might be easy to replicate with multiple code examples in this thread...

VoodooUomo
Oculus Staff

There are 0 code examples in this thread. If you have simple instructions or code that reproduces the issue please share it.

We are looking into writing our own sample on StereoKit to try and reproduce. We have a sample that does not reproduce the issue that will be shipping next week with v47 so that's another option if folks who are seeing the issue can try the same and a. see if it reproduces for them and b. see what may be the difference between that sample and their code.