mbucchia

OpenXR Toolkit was never compatible with quad views in general. It "worked" when using quad views implemented as an API layer, because that allowed OpenXR Toolkit to see stereo instead of quad views. Doing that is impossible when using quad views implemented inside the OpenXR runtime directly. The only way to have quad views and OpenXR Toolkit at the same time is to use the quad views API layer instead of the implementation inside the OpenXR runtime. I also highly recommend to stop using OpenXR Toolkit in general.

My best bet is you have OpenXR Toolkit installed, and Pimax enabled quad views by default. OpenXR Toolkit + quad views at runtime level => black screen, not supported.

I doubt it will make a difference performance-wise. There's very little overhead in PimaxXR and QVFR.

Hey, just to be clear, I am not involved in this development. This is all Pimax. I have retired from VR development entirely.

Try inspecting your log file: https://github.com/mbucchia/Quad-Views-Foveated/wiki/Troubleshooting The whole idea of foveated rendering with eye tracking is that you shouldn't notice it. So maybe you're not having any issues and everything is actually working as expected. You can also use some of the advanced debugging options to really confirm: https://github.com/mbucchia/Quad-Views-Foveated/wiki/Advanced-Configuration#options-for-advanced-debugging

90% of VR content is still OpenVR. If they had not implemented a SteamVR driver, you would not be able to run this 90% of games. By implementing a SteamVR driver, you automatically get support for both OpenVR and OpenXR applications. It's the most economical way of developing a headset. Most vendors only care to develop their own OpenXR runtime when they have unique features that SteamVR won't support, like hand, eye, face tracking. They don't look at the "SteamVR performance" picture.

That's a question I've looked into. It's a similar question that I look into a while ago w.r.t other headsets with only SteamVR drivers. Possible: Yes Difficult: Yes Hopeful: No Sony isn't releasing any proper developer SDK. The only driver that exists is the one in SteamVR. To make this driver work _without_ SteamVR, one would need to write a SteamVR Driver adapter, which would need to implement parts of the SteamVR Driver API to talk to the driver and pretend to be SteamVR. The adapter could then expose itself as an Oculus Quest for example, and plug into VDXR that way. Looking into the guts of the driver, you can see that the following SteamVR Driver API interfaces are used: IVRSettings_003, ITrackedDeviceServerDriver_005, IVRDisplayComponent_003, IVRDriverDirectModeComponent_008, IVRCameraComponent_003, IServerTrackedDeviceProvider_004, IVRWatchdogProvider_001, IVRCompositorPluginProvider_001, IVRDriverLog_001, IVRServerDriverHost_006,IVRCompositorDriverHost_001, IVRWatchdogHost_002, IVRVirtualDisplay_002, IVRResources_001, IVRDriverManager_001, IVRProperties_001, IVRDriverInput_003 Not all of these need to be fully implemented, but at least partially mocked (think like what OpenComposite does for the OpenVR API) to fool Sony's driver sufficiently. On top of that, there's a few compositor features that would need to replicate the behavior or SteamVR's compositor and which don't exist today outside of it or inside Sony's driver (eg: quad layer (not views!) rendering). There's probably over 100-200 hours of work (for a dev knowing that they are doing) to make this happen reliably. All of that for a headset that doesn't even support eye tracking which personally doesn't motivate me to go and do all this work.

@Jive @Phantom711 The use if the section is optional, any setting outside of a section (beginning of the file) will apply to all runtime/apps. To use sections, refer to https://github.com/mbucchia/Quad-Views-Foveated/wiki/Advanced-Configuration#general-notes Sections with the syntax [<string>] are matched against the OpenXR runtime name. Use the log file (see Troubleshooting) and search for string Using OpenXR runtime: to find the name of your runtime. Only matching one word is sufficient, for example if your OpenXR runtime is "Varjo OpenXR Runtime 3.10.1" then using the section name [Varjo] is sufficient. I don't recall the runtime name for VDXR, but you can look it up the log file as explained. I think it's [VirtualDesktopXR].

Report said: > The version of the Meta Quest Link app software with the fix is: 68.0.0.474.361

I have received signals that Meta is going to release a hotfix in PTC. Will still be v68<something>, but should have the particular fix to the issue. Edit: I have now received users reports that the hotfix is live on PTC.

Definitely not

Neither eye tracking nor hand tracking are usable on PC with Pico headsets.

Virtual Desktop Classic (the only version that works with a G2) is Desktop streaming only, doesn't let you stream VR games

See the latest update here

Creating a thread for visibility and cc @BIGNEWY. I received confirmation from Meta that the issue in their runtime preventing usage of OpenXR API layers such as OpenXR Toolkit, will be fixed in v69, and they are taking steps to add specific tests for this scenario

Yes, Virtual Desktop works fine with the OpenXR API layers. Virtual Desktop is made BY gamers FOR gamers.

There are many threads about this. Meta introduced a blatant bug in their update that breaks many of the OpenXR API layers out there (OpenXR Toolkit, QVFR, HTCC, OXRMC...). Then after I reported the issue to them, they ignored me. Time to move to Virtual Desktop, where the developers care and properly look after their software.

PSVR2 will only release with a SteamVR driver, which means that you can use OpenXR via SteamVR, therefore WITHOUT most benefits of OpenXR in terms of lightweightness and performance. Things like Quad Views should work, but in fixed foveated mode since it doesn't look like Sony is releasing an SDK to allow developers to access things like the eye tracker.

It's the same reason, QVFR, OpenXR-Toolkit and even a few mods not developed by me (OXRMC, HTCC) will break on v68 due to Meta's bug. Meta is breaking something fundamental that many OpenXR API layers use. I've reported the issue 1 week ago directly to the devs on the OpenXR chat. They haven't acknowledged my message Correct. I'll be checking on the status of this soon, and otherwise try a workaround.

You should be able to use Varjo's built-in option (registry change). You won't be able to tweak any settings this way however. So if you rely on custom settings, keeping Varjo-Foveated is probably a good option.

Code is 100% done in VDXR. But unfortunately it is currently blocked on an unforeseen limitation of Virtual Desktop's compositor. There's currently no guarantee this will be resolved.

Quest Link is really just a "devkit" of Meta's standalone (Android) platform. You should get that hint from the fact that you need to enable developer mode to even get these features Virtual Desktop and VDXR on the other hand are fully optimized for what people actually care about and use. We take the eye tracking data at the beginning of each frame and send it as quickly as possible to the application. No B.S in between. So I'm not quite surprised if you find it better. Haven't done any analysis myself, but I can only imagine this isn't even a thing Meta tests on PC beyond their Avatars SDK that no one else seems to use (good product though, just not what people actually care about).

Here's a very comprehensive explanation: https://github.com/mbucchia/VirtualDesktop-OpenXR/wiki/Oculus-"Runtimes"

Good insight, but no, none of this is actionable by ED, that's not code they have any reach into.

The issue is specific to "dynamic projection" ie when the foveated viewport moves from frame to frame. That only happens with eye tracking.