Display stays on regardless of proximity sensor

[Doomsdayrs]

On the Oculus CV1, Regardless of the proximity sensor, the display stays on.

Is this known?

[thaytan]

It is on my TODO list, but helpful to have an issue to remind me, thanks!

For Rift S I added code to trigger the displays on/off automatically, but I'm not sure where the prox sensor report is for CV1 right now.

[l33tlinuxh4x0r]

I can confirm that this is also a bug with the HP Reverb G2.

[l33tlinuxh4x0r]

looks like this might be an OS issue... With Linux for me, gnome detects this as a display when it is not being used by OpenHMD which keeps the headset on. OpenHMD appears to be grabbing it and dismissing it correctly.

[Danny-Dunn]

Success!(kinda)

I have a working way to read the proximity sensor from the Rift in Danny-Dunn/OpenHMD/tree/rift-prox-sensor. Currently, it is just reported as a button attached to the HMD, and the displays will not turn off when the sensor is out of range.

I tried using the existing encode_enable_components to turn on and off the displays, but this isn't ideal, as it seems to completely disable the whole display system(including the display controller/HDMI link). When this is called to turn off the displays, they turn off, the HDMI disconnects, and the indicator light inside the headset turns orange(it's supposed to be white when the headset is connected and running and off the user's head). When it is called to re-enable the displays, it takes 3-4 seconds, probably because the display controllers and the HDMI have to completely
re-initialise. SteamVR doesn't seem to care about this(but I opted to disable it because other system configs may react differently) and will resume rendering to the displays, but it isn't a great user-experience.

I have 2 guesses for how the Oculus software sleeps the displays.

1. It has another USB command that it sends to sleep the displays.(I am going to search for this)
2. Instead of telling the HMD to do anything, it just sends empty frames to the displays. This could be a challenge since this requires having control over the direct mode output to the headset(being a compositor?). This is outside the scope of OpenHMD. It also seems that the documentation for how to implement a SteamVR driver that bypasses SteamVR's direct output is non-existent, others have tried and failed to do this.

[Doomsdayrs]

@Danny-Dunn its likely the first, as sending empty frames would cause backlight

[Danny-Dunn]

@Danny-Dunn its likely the first, as sending empty frames would cause backlight

The displays are OLED and lack a backlight

[Doomsdayrs]

@Danny-Dunn its likely the first, as sending empty frames would cause backlight

The displays are OLED and lack a backlight

. . . oh.

Well that makes this a lot more complicated