mbucchia

Few things that may be useful. With OpenXR supported in the game, you do not need OpenComposite anymore, regardless of what headset you use. The goal of OpenComposite is to bridge OpenVR to OpenXR. Using OpenComposite now would be redundant. With OpenXR, you may have the opportunity to either USE or NOT USE SteamVR. See the table below for headsets capable of native support (bypassing SteamVR): Headset brand Has native OpenXR support? (without SteamVR) Windows Mixed Reality (HP Reverb, Samsung Odyssey…) Yes Oculus (Rift, Quest, Quest 2, Quest Pro…) via Link Yes Oculus (...) via Virtual Desktop No Varjo (Aero, VR-3…) Yes Pimax (5K, 8K…) Yes (via PimaxXR) HTC Tier 1 (Vive original, Vive Pro, Vive Pro 2) No HTC Tier 2 (Vive Cosmos, Vive Focus) Yes (via VIVE Console) Valve Index No Pico (Neo 3, Neo 4) No NOTE for Oculus users: if you are using Virtual Desktop, you MUST USE SteamVR (as of date of writing 2023-01-26). Only Link cable and Air Link will work with Oculus native OpenXR support. NOTE: headsets in the list above without native OpenXR support can still use OpenXR, but you MUST USE SteamVR as your OpenXR runtime, as explained directly below. If you want to USE SteamVR with OpenXR Why/when to use SteamVR OpenXR? - I have a headset that does not support OpenXR natively (eg: Valve Index). - I rely on SteamVR features (like overlays or controller button bindings). - I rely on SteamVR 3rd party apps (like fpsVR or OVRMC). You must set SteamVR as your OpenXR runtime and run DCS.exe with --force_OpenXR (see BIGNEWY post above): If you wish to revert to using OpenVR instead of OpenXR Why/when to use OpenVR? - I rely on OpenVR 3rd party injections (mods) like ReShade or vrperfkit - I could not get OpenXR to work You must run the game with the extra command-line argument: DCS.exe --force_steam_VR If you want to NOT USE SteamVR at all Why/when to use OpenXR without SteamVR? - I have a headset that supports OpenXR natively (eg: HP Reverb). - I want to remove the overhead of SteamVR (lower memory usage and possibly higher image clarity). The procedure varies by headset/brand, and you must run DCS.exe with --force_OpenXR (see BIGNEWY post above): WINDOWS MIXED REALITY (use EITHER method) From Mixed Reality Portal: From OpenXR Tools for Windows Mixed Reality: OCULUS (Link cable or Air Link only) From the Oculus app: VARJO From Varjo Base: PIMAX You must download unofficial Pimax OpenXR support: Home · mbucchia/Pimax-OpenXR Wiki · GitHub Then from PimaxXR Control Center: HTC (Vive Cosmos and Focus only) You must install the HTC Vive Console For SteamVR. Once opened: To inspect the current configuration on your system (and make sure OpenXR is properly installed and configured), you can use OpenXR Explorer. It will show you the currently active OpenXR runtime (which should match your device if you want things to work!):

Thanks. Can you also check with the dev team if there is a way to disable usage of XR_VARJO_quad_views for Varjo users, via a command-line argument for example? That's an atypical mode and it is breaking some of the mods out there. Cc @zildac Also, apps should always check for view configuration availability via xrEnumerateViewConfigurations(). That doesn't seem to be the case here and DCS seems to activate XR_VIEW_CONFIGURATION_TYPE_PRIMARY_QUAD_VARJO regardless of whether it is enumerated, as long as XR_VARJO_quad_views is available from the runtime. This is not a conformant behavior when using OpenXR.

There is a safe mode option in the desktop companion app. Use that to start the game, then restore defaults from the menu. https://mbucchia.github.io/OpenXR-Toolkit/troubleshooting.html#start-in-safe-mode Sounds like your issue is that you had enabled Motion Reprojection indeed.

Working fine for me and several other reports on my Discord. Seen good reports with G2, Quest 2, and Pimax (EDIT: Add Quest 2 after report below). However the bad news is for Varjo users, where it just won't work because the new engine uses VARJO_quad_views, and this will not be supported. Unless there is an option (maybe ED can tell us) to disable quad views, there will not be support for Varjo anymore. Also if you are on WMR and using Motion reprojection enabled via OpenXR Toolkit, you want to disable Motion reprojection. There's a bug in the game engine that causes that to crash (not related to OpenXR Toolkit or OpenXR for WMR).

You always have the option to set SteamVR as your OpenXR runtime. That should work pretty universally and re-enable the use of things like fpsVR.

You may forward to dev team: the game is doing 2 back-to-back xrWaitFrame() from the same thread, which causes a deadlock. nullThis condition is probably exacerbated by the frame timing of motion reprojection. Read more about xrWaitFrame() deadlocks here: OpenXR-Guide/frame_submission.md at main · KhronosGroup/OpenXR-Guide (github.com) Happy to find a more official channel to discuss. Thanks.

OpenXR Toolkit is not related/endorsed in any way by Microsoft, OpenXR Toolkit is my week-end project. My comments associated with the development of OpenXR Toolkit shall not reflect in any way the positions/views/opinions of Microsoft. Please do not associate anything WMR here. The moment you are doing this is the moment trouble begins for me. I have deleted my previous comment from Discord and I publicly apologize for my comment that did not reflect the positions/views/opinions of my employer. (EDIT: To be clear, my comment was also taken out of context when copy/pasted on this forum... it was not specifically targeting this developer or this title.) I have no desire to pursue any developments in OpenXR Toolkit related to this title, and therefore this discussion is no longer productive. (EDIT: To be clear, this does not mean OpenXR Toolkit will stop working, I just do not have plans to write new features specifically for this title, like it had been done on several occasions in the past.) (EDIT: One more "To be clear": on a previous page of this thread, I had mentioned that my team at Microsoft (which again is a completely separate effort from OpenXR Toolkit) is always open to help developers with migrating their applications to OpenXR, and my team has a track record of helping a handful of major game studios doing so. This is a permanent offer that always stands, including for the developers of this title, regardless of any discussion that took place regarding my OpenXR Toolkit project.) Asking @moderator at this point (so @BIGNEWY I think?), can we please lock this thread? Thanks.

There is no dependency on OpenXR Toolkit needing OpenXR Tools for WMR. If you have OpenXR Toolkit, you only really need OpenXR Tools for WMR if you want to enable WMR beta ("Preview runtime"). Also @shambler6691 you should only get OpenXR Tools for WMR if you have a WMR device (eg: HP Reverb). It's not useful with other headsets.

Great to hear and thank you for the feedback! We will be promoting that beta to stable in the next few days (if not today perhaps).

Yes, to be clear this is a deficiency of OpenXR Tools for WMR, not OpenKneeboard. But it is what it is today. I've been encouraging people to use OpenXR Explorer as well.

Are you on Windows Mixed Reality? If so, definitely give the beta a try: https://steamcommunity.com/games/719950/announcements/detail/6096216107292749119 We fixed an issue with a memory leak that caused VRAM to fill out.

I can't remember exactly what OpenKneeboard did, but I thought the latest version took extra care to not break OpenXR Tools. Better is to ask Fred on the OpenKneeboard Discord.

Most common cause for this is you have an OpenXR API layer such as OpenKneeboard, XRNS or OXRMC that is installed outside of your ProgramFiles folder. Check your registry at HKLM\Software\Khronos\OpenXR\1\ApiLayers\Implicit. There shouldn't be any key pointing to a file outside of ProgramFiles. Delete any offending key to resolve the issue.

It's always been like that. As edmuss mentioned, you need to have sufficient headroom at 60/90 for it to stay off. If too close to dropping frames, it will enable itself.

Auto is misleading and it only means enabled in FS2020. For other games you want to use Always on, which is a misnomer, Always on means Always on standby, and it only engages when you cannot hit the refresh rate 90 or 60 based on your WMR settings. So for short: use Always on, because it does exactly what you described you want it to do. Always on does what you want (only engaged when needed based on frame rate). This is the same exact behavior as OpenXR Toolkit Unlocked mentioned in your other comment. Having something called Auto was a huge mistake we made and I am going to remove it ASAP due to all the confusion in creates.

Not sure what "cut in" means, but today this is how MR works: it only engages if you cannot hit refresh rate.

Turbo Mode disables all v-sync (frame wait needed to reduce latency) and this means letting the game completely max out your GPU by just going as fast as possible without trying to reduce latency. Because the platform does a good job at late-stage reprojection (compensating the images for head movements), the extra latency is not that important, and the gain in framerate is well worth it. Your mileage may vary however: Turbo Mode can have as high as 20 FPS increase in some situations, but can also not give much in others.

Run DCS.exe with additional parameter --force_steam_VR

This isn't entirely correct. Turbo Mode will interfere with Motion reprojection, but it is being discussed as "turn it off" anyway in the conversation. Turbo Mode heavily relies on Spatial reprojection (something that is always on), it makes it work a little harder due to extra latency, but it's an essential part of the process. Without it, Turbo Mode would create a wobbly mess. Regarding WMR Motion reprojection, some significant improvements are currently in testing before release, and my tester with DCS claimed "it looks significantly better for me [on a 3080Ti]".

Look into the registry at HKEY_LOCAL_MACHINE\Software\Khronos\OpenXR\ApiLayers\1\Explicit. You probably have an entry to a file not under ProgramFiles, which would cause this error. Older versions of OpenKneeboard caused that IIRC. Or misinstalled versions of XRNS or OXRMC. Attach a screenshot if unsure.

Just to be clear, these are bugs of OpenComposite and nothing to do with your "$500 controllers", the vendors that made them, and the developers of the OpenXR platform software you are using.

Correct.

If you join the OpenXR Toolkit discord (see our website), then the link will become accessible.

There will be a public version available at some point, probably a week or two from now. I insist again this is an OpenComposite bug. I wish they could release a fix for it themselves since they don't have a release cycles (they just release whenever). OpenXR Toolkit however is on a release cycle that follows certain testing period, hence the delay.

Thanks for posting. This is purely an OpenComposite bug, which I have reported to the OpenComposite developer. I am not sure when/if they will address it. Next version of OpenXR Toolkit will implement a fix in case OpenComposite is not fixed by then.