Controller input with headset off

According to the OpenXR spec, action inputs are received only when the session state is XR_SESSION_STATE_FOCUSED, and focused state is active only when the headset is on. This means that I can get controller pose state while the headset is off but there is no way to get controller button state.

Two questions:

  1. Is there a good reason for this design decision? Why shouldn’t it be possible to continue to use controller buttons when the headset is not on?
  2. Is there any way to work around this? I could not find any way to force the session state to change or to access the button state without having active action inputs.

TIA for any help.

When you lose FOCUSED, it probably means that a dashboard is pulled up or some other case where your application is not active. Some pose data may flow (to allow head motion to work in the environment, so your world doesn’t freeze when you pull up a dashboard or system menu), but not all input data will flow (so your app can’t sniff e.g. a credit card number being entered in a store interface).

Can you point out where you saw that you will get controller pose when not focused? I want to make sure it’s clear there that you may get it, but (e.g. in the on-screen-keyboard credit card scenario) you aren’t guaranteed it. I think (off the top of my head) you might be guaranteed head/view pose maybe?

If the headset is turned off, I would suspect you would not get any data, you’d probably get a session exit event flow. If the headset is not worn, your session state will also change, but I think that it will go further than just “not focused”. If you want the input data without rendering to the headset, let your runtime vendors know they should work with others in the group to firm up a multi-vendor “headless” extension :slight_smile: (the Monado runtime I work on has such an extension, though work on a better extension is somewhat constrained by fitting in to the session lifecycle you’ve mentioned…)

Thank you for your response.

To be clear, I am talking about the headset still turned on but removed from the user’s head, and a sensor is in the headset sends a signal that it is no longer being worn. When this happens (at least in my experience), the state changes from FOCUSED to VISIBLE and button input no longer works. Pose input continues to work, although I’m not sure the spec mandates that.

I do not want to go to a full headless session, as I want the headset to work when put on. I just want input to work when it is taken off.

The spec seems very ambiguous on this, so there is likely a lot of leeway on how runtimes choose to implement it.

I’m guessing your issue comes from using SteamVR. Since the last few betas they changed it to very aggressively changing the session state when the headset is taken off, along with only enabling the input profiles when the headset is worn. Since it’s not possible to turn off the behavior, it makes development difficult with forcing you to take the headset on and off constantly. The interaction profile behavior is also not clearly documented, leading to it being interpreted as a bug.

OK, that’s what I figured you were talking about, but I put the stuff about headset-entirely-off in there just in case I was wrong.

If you do xrSyncActions when your session is not focused (so, headset doffed, for example), the spec says: " If session is not focused, the runtime must return XR_SESSION_NOT_FOCUSED, and all action states in the session must be inactive."

It is intentionally left to the runtime how they want to drive the focused/visible parts of the state: we didn’t want to say “if you have a user sensor” and thus imply you can’t use e.g. IMU data to detect the headset was set down, etc.