ChristophHaag/SteamVR-OpenHMD

[RIFT S] No Display Output Windows 64-bit MSVC 2019

RSDNTWK opened this issue · 14 comments

For some reason the windows build is unable to initialise the display even though the headset and all drivers are installed. We even hardcoded the settings in ohmd_config.h. No idea what's going on. Here's our vrserver log from steamvr. We are using Nvidia Graphics Cards.
vrserver.txt

This might be related to the display rotation. In Linux, one needs to use xrandr to rotate the display first. The problem is that OpenHMD reports the logical display size (2560x1440), but the display presented to the OS is physically portrait (1440x2560).

Not sure how that can be resolved in windows given the hardware isn't seen in the nvidia control panel itself. It's usually handled directly using the oculus software.

For a test, you might try swapping the display width/height in GetWindowBounds() and see if SteamVR finds the output then. It won't render correctly, but it'll help confirm that's the problem.

Sadly it has no effect whatsoever. It still displays the same values. And there is still nothing displaying at all.

I made this for proper display rotation #58

It won't do anything for the Rift S because OpenHMD doesn't give us info about its display rotation. But it's set up to allow easy additions, so after the WVR entry you can add your own like

       if (strcmp(prod, "VR-Tek WVR") == 0 && m_renderViewportWidth == 2560 &&
            m_renderViewportHeight == 1440) {
          eye_rotation[0] = EYE_ROTATION_RIGHT;
          eye_rotation[1] = EYE_ROTATION_RIGHT;
          DriverLog("Force eye_rotation: Right for %s\n", prod);
          projection_matrix_rotated = false;
        }

       if (strcmp(prod, "Rift S") == 0) {
          eye_rotation[0] = EYE_ROTATION_RIGHT;
          eye_rotation[1] = EYE_ROTATION_RIGHT;
          DriverLog("Force eye_rotation: Right for %s\n", prod);
          projection_matrix_rotated = false;
        }

On Linux this is enough to get SteamVR to use direct mode. On Windows there may or may not be additional requirements like giving SteamVR the correct EDID vendor string. I don't know how, but it'd probably be an additional setProp thing.

I think you might be right about the EDID, in that case something like this might work:

	vr::VRProperties()->SetInt32Property(m_ulPropertyContainer, Prop_EdidVendorID_Int32, 0x3ed2);
	vr::VRProperties()->SetInt32Property(m_ulPropertyContainer, Prop_EdidProductID_Int32, 0x0012);

(those values might need byte swapping, I'm not sure which way around SteamVR wants them)

After trying both of your suggestions we were able to get further however SteamVR just fails at DXGI thread failed to get SDL display index which could explain why the display still isn't working.

ValveSoftware/openvr#422 seems directly related then

We did try everything suggested however nothing worked. It doesn't seem to work. it seems like there is an issue with the direct mode. Not sure how to resolve.

You said you "got further"? Does that mean you got past the DXGI thread failed to get SDL display index error to something else?

We got as far as the DXGI error but we did get the windows background when running it in extended mode. However the steamvr overlay still couldn't render.

Note sure if this will help but the recent changes produced this result.
Sun Oct 17 2021 04:15:44.067 - openhmd: get controller component IVRDisplayComponent_002 | <nothing> Sun Oct 17 2021 04:15:44.067 - openhmd: : no Sun Oct 17 2021 04:15:44.067 - openhmd: get controller component IVRDriverDirectModeComponent_006 | <nothing> Sun Oct 17 2021 04:15:44.067 - openhmd: : no Sun Oct 17 2021 04:15:44.067 - openhmd: get controller component IVRCameraComponent_003 | <nothing> Sun Oct 17 2021 04:15:44.067 - openhmd: : no Sun Oct 17 2021 04:15:44.067 - openhmd: get controller component IVRVirtualDisplay_002 | <nothing> Sun Oct 17 2021 04:15:44.067 - openhmd: : no Sun Oct 17 2021 04:15:44.071 - DXGI thread failed to get SDL display index

@thaytan @ChristophHaag Any ideas on what is happening? It's the first time we've seen these messages appear.

I don't think those messages are caused by anything that's changed on the SteamVR-OpenHMD or OpenHMD front - they must be from a SteamVR update