OpenVR driver emulating synthetic devices does not work with legacy applications

[shashiuli-ntnx]

Hello,

We are trying to get Steam VR working on a remote virtual desktop with Oculus Quest2 running a web browser that connects to the virtual desktop. The VR device (and web browser) and the virtual desktop (running SteamVR) are connected over a network. The device input is serialized and sent over the network to an OpenVR driver (developed in-house) running inside SteamVR, on the virtual desktop. The VR graphics stream is then sent the other way over the network and rendered on the web browser running on the remote terminal.

The OpenVR driver emulates an HTC Vive HMD and left/right controller devices by advertising 'controler_type' : 'vive_controller' in the controller profile. It also along the input from the actual device to the openvr driver on pre-defined input paths as described here. The devices are emulated using the SteamVR input system and there are no other USB emulators running on the virtual desktop.

We have tested this setup for some of the Steam VR native apps using the 'SteamVR input' system (like the SteamVR tutorial) and it seems to render the emulated controller and respond to input and generally work very well. However, applications using legacy input (like Google Earth VR) don't seem to be responding to any of the input. The emulated controller does not even render in the application as they do on the SteamVR input apps. Google Earth, in particular, has been set up with the legacy input bindings for Vive with the Vive input buttons/trackpad mapped to the right actions as far as I can tell (grip/trigger/trackpad etc).

The logs for vrclient_earth.txt or vrserver.txt don't seem to indicate any errors. The devices seem to have been advertised to the Earth app correctly. I have attached a system report for after Google Earth was run. Is there anything else that legacy applications need (other than the legacy bindings) that they need to be set up with ?

SteamVR-2022-10-18-AM_09_08_28.txt

Help appreciated.

[Rectus]

First you might want to determine if the application-side API is outputting legacy input at all. The DirectX 12 version of the hello_vr sample application still uses the legacy input system and can be used to test this. It will hide the controller model as long as any button input is active.

Many legacy apps use custom logic to determine what kind of controllers you have, and may be hardcoded to only work with certain kinds of controllers. There is no standardized way they do this. Most of them likely read the name of either the controller or HMD from the tracked device properties, so your driver might need to return identical strings to the Vive.

[shashiuli-ntnx]

Thanks for the reply. The hellovr_dx12 sample starts up and then seems to either crash or just go away after SteamVR shows the 'Next up' window for it. I am not sure what to expect. Either way, the attached system crash report that was generated after it was run, seems to suggest none of the actions got mapped. No other errors were indicated. SteamVR-2022-10-20-AM_10_22_03.txt

[Rectus]

The logs suggest the sample crashes before it can begin rendering. Looking at my own logs, it doesn't seem to print out the mapped actions for legacy apps. The only thing I can see that looks off is that the controllers are mapped to device ID 10 and 11. It is not invalid behavior, but it is possible that there are applications that hardcode the IDs they check for to ID 1 and 2, since most drivers seem to consistently assign them that way.

I'd suggest debugging the sample app to see what causes it to crash. If something is causing it to break, it may affect other apps as well.

[shashiuli-ntnx]

Really appreciate the help. Is the device ID something that the driver can control by setting a property? ALso the hellovr_dx12 crash has the following callstack

00 00d3f0f0 0062dc65     hellovr_dx12!CMainApplication::CreateAllShaders+0x4f2 [C:\Users\shashikiran.uli\Code\openvr\samples\hellovr_dx12\hellovr_dx12_main.cpp @ 933] 
01 00d3f31c 0062d478     hellovr_dx12!CMainApplication::BInitD3D12+0x6f5 [C:\Users\shashikiran.uli\Code\openvr\samples\hellovr_dx12\hellovr_dx12_main.cpp @ 634] 
02 00d3f798 00635c52     hellovr_dx12!CMainApplication::BInit+0x4f8 [C:\Users\shashikiran.uli\Code\openvr\samples\hellovr_dx12\hellovr_dx12_main.cpp @ 449] 
03 00d3f870 006211c2     hellovr_dx12!SDL_main+0x42 [C:\Users\shashikiran.uli\Code\openvr\samples\hellovr_dx12\hellovr_dx12_main.cpp @ 2234] 
04 00d3f88c 0063783e     hellovr_dx12!WinMain+0x72 [c:\buildslave\sdl_win32\build\dev\src\main\windows\sdl_windows_main.c @ 156] 
05 (Inline) --------     hellovr_dx12!invoke_main+0x1a [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 102] 
06 00d3f8d8 76a5fa29     hellovr_dx12!__scrt_common_main_seh+0xf8 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
07 00d3f8e8 772b7b5e     KERNEL32!BaseThreadInitThunk+0x19
08 00d3f944 772b7b2e     ntdll_77250000!__RtlUserThreadStart+0x2f
09 00d3f954 00000000     ntdll_77250000!_RtlUserThreadStart+0x1b

[Rectus]

Not sure. I think the device IDs are assigned sequentially by the order they are added to the driver. Seems like hellovr is failing to compile the pixel shader.

[TheDeveloperGuy]

Find the source code for FakeVive and see what it is overriding to appear as a Vive to applications. You can then use the same values in your driver for applications to think they're running on Vive.