BIsHmdPresent always returns true

[zeux]

Calling VR_IsHmdPresent (before calling VR_Init) now seems to always return true if SteamVR is installed at all - even if no headset is plugged in or no headset has ever been plugged in on the system in question.

This used to work in January; I'm not sure which specific SteamVR update changed this behavior - it looks like it's been happening since Feb 14th at least but I can't date the issue any earlier than that.

This happens on latest non-beta SteamVR (v1485823399) with OpenVR 1.0.5 and OpenVR 1.0.6. The expected behavior is that the return value is false unless a headset is actually plugged in, which is how the function behaved in January.

The reason this is an issue for us is that VR_Init starts SteamVR unconditionally now; we need to check if the user has a VR device installed and plugged in without starting up SteamVR - it used to be possible with VR_IsHmdPresent but since it now returns true we have to try to call VR_Init (which fails with HmdNotPresent, as expected).

[TheDeveloperGuy]

AFAIK this was changed in a recent SDK version. Previously there was a "is HMD present" function in the HMD driver which was used to do an early detection of the HMD (before Init). Now that functionality is implemented by OpenVR itself where it does a USB vendor/product check to see if the HMD is plugged into USB (obviously this won't work with for instance wireless HMDs).

[zeux]

That's what the release notes say, however the source of the SDK still calls BIsHmdPresent. Also the prebuilt DLL doesn't seem to use any USB discovery functions - not sure how closely is the source code matching the built binary, since we're using SDK from source it's possible that BIsHmdPresent is now hardwired to return true but the DLL version of the SDK magically works... Let me check that.

[zeux]

No - the DLL version of the SDK doesn't magically work. Here's the simple program I'm testing this with:

#include "openvr.h"
#pragma comment(lib, "openvr_api.lib")

#include <stdio.h>

using namespace vr;

int main()
{
	printf("VR_IsRuntimeInstalled: %d\n", VR_IsRuntimeInstalled());
	printf("VR_IsHmdPresent: %d\n", VR_IsHmdPresent());
	EVRInitError error;
	printf("VR_Init: %p\n", VR_Init(&error, VRApplication_Scene));
	printf("VR_Init error: %d (%s)\n", error, VR_GetVRInitErrorAsSymbol(error));
	return 0;
}

And here's the output in its entirety:

VR_IsRuntimeInstalled: 1
VR_IsHmdPresent: 1
VR Server (v1485823399)

Using breakpad crash handler
Setting breakpad minidump AppID = 250820
Forcing breakpad minidump interfaces to load
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
VR_Init: 00000000
VR_Init error: 108 (VRInitError_Init_HmdNotFound)

Note the log messages coming from running SteamVR. As before, this is from a system that doesn't have Vive and has never had Vive installed - fresh SteamVR installation.

[TheDeveloperGuy]

Yeah, I'm just going from the point of view of a driver developer (ie. what we have to implement on that side), can't say whether OpenVR is actually doing anything with the VID/PID we give for this purpose.

[kyle-emmerich]

Any updates on this? Still a problem for any hybrid applications.

[zeux]

Verified it still happens with OpenVR 1.0.7 and SteamVR 1492726420 - repro program above still working as described, with VR_IsHmdPresent returning true on a fresh SteamVR installation with no Vive.

[zeux]

Also happens with current SteamVR beta 1493337050.

[zeux]

Here's a workaround that works if somebody else is hitting this issue:

bool VR_IsHmdPresent_Workaround()
{
	// No runtime - no need to scan for USB devices
	if (!VR_IsRuntimeInstalled())
		return false;

	// Runtime is installed; VR_IsHmdPresent is known to always return true so let's try to see if we have any Valve USB devices plugged in
	const GUID GUID_DEVINTERFACE_USB_DEVICE = {0xA5DCBF10L, 0x6530, 0x11D2, { 0x90, 0x1F, 0x00, 0xC0, 0x4F, 0xB9, 0x51, 0xED} };

	HDEVINFO hDevInfo = SetupDiGetClassDevsA(&GUID_DEVINTERFACE_USB_DEVICE, NULL, 0, DIGCF_DEVICEINTERFACE | DIGCF_PRESENT);
	if (hDevInfo == INVALID_HANDLE_VALUE)
		return false;

	SP_DEVICE_INTERFACE_DATA DevIntfData;
	DevIntfData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);

	unsigned int deviceIndex = 0;

	bool lighthouseFound = false;

	while (SetupDiEnumDeviceInterfaces(hDevInfo, NULL, &GUID_DEVINTERFACE_USB_DEVICE, deviceIndex, &DevIntfData))
	{
		char Buffer[256];
		PSP_DEVICE_INTERFACE_DETAIL_DATA_A DevIntfDetailData = reinterpret_cast<PSP_DEVICE_INTERFACE_DETAIL_DATA_A>(Buffer);
		DevIntfDetailData->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA_A);

		if (SetupDiGetDeviceInterfaceDetailA(hDevInfo, &DevIntfData, DevIntfDetailData, sizeof(Buffer), NULL, NULL))
		{
			unsigned int vid, pid;
			if (sscanf(DevIntfDetailData->DevicePath, "\\\\?\\usb#vid_%x&pid_%x#", &vid, &pid) == 2)
			{
				if (vid == 0x28de)
				{
					// list of product ids is from lighthouse/driver.vrdrivermanifest
					lighthouseFound = lighthouseFound || (pid == 0x2000 || pid == 0x2012 || pid == 0x2101 || pid == 0x2300);
				}
			}
		}

		deviceIndex++;
	}

	SetupDiDestroyDeviceInfoList(hDevInfo);

	return lighthouseFound;
}

It's unfortunate that we have to resort to that. This will probably break if Valve ever revs the lighthouse cameras (I'm actually not 100% sure if the product ID I'm getting is for the link box or camera or what).

[JoeLudwig]

I can't reproduce this problem on my machine here with no HMD plugged in.

The code above is essentially what BIsHmdPresent does under the hood using the VID and PID combinations specified in the installed drivers' manifest files. Maybe you have the null driver, the sample driver, or some other driver that specified . installed?

VID 28DE is Valve and 2101 is one of the dongles inside the headset.

[zeux]

@JoeLudwig I'm not sure - the code sample from earlier in this thread returns true on the default SteamVR setup. The default setup does include "null" folder in C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\null but I don't know if it is included into the presence check. Is there a way to tell?

[zeux]

@JoeLudwig In the compositor logs, I do see both lighthouse and null driver getting loaded:

Wed May 03 2017 11:16:34.657 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\resources\settings\default.vrsettings
Wed May 03 2017 11:16:34.658 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\lighthouse\resources\settings\default.vrsettings
Wed May 03 2017 11:16:34.658 - [Settings] Load Default Json Settings from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\null\resources\settings\default.vrsettings

I did not do anything special to install the null driver - this is a fresh Steam & SteamVR setup. Is it possible that it's mistakenly installed by default and returning "always present" which is what causes the issue?

[zeux]

@JoeLudwig So it appears that both oculus and oculus_legacy drivers cause the presence to return "true" - removing both of them from drivers/ folder fixes the issue, but leaving just one of them there makes it happen. (null driver is fine - it seems like it's disabled by default)

Note that this is on a system that had never had any Oculus software installed or hardware plugged in.

[JoeLudwig]

I figured out what's going on here. A fix will go into the next SteamVR Beta update (which will probably be next week.)

[zeux]

@JoeLudwig Thank you! Since I'm not familiar with SteamVR release schedule, any idea when this might end up in a non-beta release? (trying to figure out if I want to ship the workaround temporarily or just wait for SteamVR)

[JoeLudwig]

It's hard to say for sure, but it'll probably be in the build everybody uses in late June.

What are you enabling/disabling based on the results of this function? If it's something like switching to VR mode automatically when hardware is present, you might be better off using Steam launch options...