State of proximity sensor is not reported if dashboard is up

[bddckr]

Using GetControllerState* I'm getting the button pressed state of k_EButton_ProximitySensor for the HMD tracked device index.

While the dashboard is visible the proximity sensor button is reported as being not pressed.

The actual issue stems from the fact that the dashboard captures input focus which can be seen by checking IsInputFocusCapturedByAnotherProcess.

Is there a way to get the proximity sensor data even when the dashboard is up? Is the behavior above actually desired or could it be a solution to always report the proximity sensor "button" state?

[asaeed]

Did you ever figure yjis out @bddckr ? Having the same issue with the Unity OpenVR plugin, using the following (in case it helps anyone):

SteamVR_Controller.Input(0).GetPress(EVRButtonId.k_EButton_ProximitySensor)

Works great to detect if someone is wearing the headset, but stops working when any overlay is visible. Seems there is an underlying issue with OpenVR. Is it considered a bug?

[bddckr]

I consider this a bug - no matter what app type you OpenVR.Init with, you just don't get any input state of any tracked device while the dashboard is up.

I assume this is because they want to ensure (scene) apps don't take these inputs but honestly it should be up to the app developer - we have API in OpenVR to tell us about when to hide our rendermodels, when to stop taking input data and when to pause rendering completely after all.

---

There is nothing you can do here as far as I am aware, it's just not possible.

[muchcharles]

Which type of non-scene apps can get all inputs all the time regardless of overlay state? VRApplication_Background?

The only workaround I can think of is spawn a subprocess with it's own IVRSystem registered as a VRApplication_Background (if that gets all inputs), and then communicate the sensor state through IPC. Or create a separate IVRSystem in the same process if that is allowed. Both are fairly nasty workarounds to have to do.

[bddckr]

I am using both VRApplication_Background as well as VRApplication_Scene. Any of them gets no proper input state while the dashboard is up.

[bddckr]

My initial observation still seems to be correct:

Despite there being API to tell an app whether to render models or use input the system additionally insists on giving false information while the input focus is "captured" by the dashboard (process).

The only real hacky workaround I potentially see is hooking the vrdashboard process and forwarding its calls to get input to our apps. Such a big task that can break at any time.

I would love a change here so there is no "input focus capture" - there is API for that. If the reason to not do that is that older titles are not obeying the rendermodel/input focus API I'd suggest to just add a flag to the Init parameters or something so we can tell the system we're properly implementing things so please give us proper data even though the dashboard is up.

[muchcharles]

This is even worse for me now. I've only seen this on WMR so far and haven't seen others, but now I'm getting:

SteamVR menu is open: proximity sensor reports triggered, always.

SteamVR is closed: proximity sensor reports not triggered, always.

Are you seeing the same? Seems to happen on beta and non-beta branch.

[bddckr]

We sadly had to move away from using the proximity sensor. We're checking for activity solely on movement now which isn't handling all use cases but that's the best we can get for our case right now.

I didn't check out the latest behavior.

[tdbe]

We sadly had to move away from using the proximity sensor. We're checking for activity solely on movement now which isn't handling all use cases but that's the best we can get for our case right now.

I didn't check out the latest behavior.

If you poll the proximity sensor every frame, you can read it as false while the dashboard is on. This is not perfect but good enough as you'd want to pause (or whatever) your game while the dashboard is on anyway. I'm polling instead of using events because obviously the events can be eaten up as you say by the dashboard and then not know the state of the headset when the dashboard is off.

reference:https://gamedev.stackexchange.com/a/164783/19895

[bddckr]

That doesn't work for my use case. Customers are getting out of VR and leaving the headset in the state it is in, which often means the dashboard is up at that point. From then on it can be left as is for hours.

Long story short: The proximity sensor is good enough for a game, but not something that runs in the background and wants to rely on it as an activity check.

[tdbe]

Oh so you want to differentiate between the headset being off while not in the dashboard, and the headset being on or off while being in the dashboard. That is a valid request.

[Hokage3211]

I'm also having problems where when the dashboard is pulled up, the steamVR Unity plugin does not report any changes in controller state, so I'm unsure how to make an overlay that needs the position of the controllers, as well as their current input values, to work properly.

[muchcharles]

The latest SteamVR beta now incorporates proximity sensor more into activity level (now for deactivating instead of just activating), so this stuff seems to be fixed now if you use the activity level API over querying the sensor through the input api.