mbucchia

Appreciate that but obtaining a signing certificate would take like 2 weeks (the whole idea of it is that they verify you are the person who you say you are, so it's a slow process, sometimes might require to visite a notary). Then on top of it, there are several hours of work to setup the new signing process on the cloud. My hope is something that simple and easy will be fixed by then. Meanwhile there are multiple solutions: - Use DCS ST (single-threaded), make sure to run with `--force_OpenXR`) - If you are on Varjo, you can revert to using Varjo-Foveated instead of Quad-Views-Foveated.

I can't speak for ED, my guess is just like any software team, the more consuming part isn't the code change itself but the review, validation and rollout process that comes with it. From the code change itself, I don't know what their code looks like, but I can't imagine that them storing the proper FOV values (they retrieved from xrLocateViews() to compute the projection matrix) into a variable that follows the frame's lifetime until submission (via xrEndFrame()) would be complex. The code in QVFR and VFR does that, and it's something like 20-30 lines of code that were written in well under an hour.

Not a Varjo issue. DCS submits information incorrectly to OpenXR. My original post from March 2023 had a screenshot of the OpenXR calls that made the problem very obvious, but somehow the forum doesn't have the image anymore and it shows as a broken URL... Edit: ugh the broken link is my fault, my image file was hosted on Discord, and with the deletion of my server, it's gone.

I assume you mean "Varjo native DFR" as in the new registry key they've released in 4.3. That would be correct, the Varjo runtime doesn't do the incorrect FOV submission "recovery" that I added in Varjo-Foveated and Quad-Views-Foveated. That's because this workaround is super sketchy (we guess which dynamic projection the game should have submitted), it uses a FOV cache to try to re-correletate the FOV information with the previous frame(s). This is why I only activate this if I am sure the app is DCS, since this is fragile code that could break other apps intentionally doing FOV manipulation. Note that this isn't an uncommon bug that ED have in their code: there's quite a few apps doing incorrect pose/FOV submission, but most of the time it only affects ever-so-slightly the reprojection (or adds a bit of instability). Here with the very low latency eye tracking, the effect is absolutely dramatic.

Ahaha yes that's right. This rename is also going to be another source of issues for that scenario

I've explained my position below. TL;DR, no I cannot do much without creating more problems for myself (eg: unsigned build that would break other apps), for an issue that I have already spent HOURS explaining in details to ED, and that isn't even my bug in the first place.

Reminder that Varjo-Foveated requires you to turn off OpenXR Toolkit, in case that's your issue here.

FYI this is the specific line that checks for DCS and enables the workaround to their incorrect multi-thread frame submission logic: https://github.com/mbucchia/Quad-Views-Foveated/blob/957ff0327185ea29acc41fc86c4cdc3caf428fb9/openxr-api-layer/layer.cpp#L175 The new version of DCS seems to report "DCS" instead of "DCS World". As mentioned above, while this looks like an easy change for me, it isnt: 1) ED needs to provide the real fix, as explained in March 2023 and again in December 2023. If the real issue had been addressed at the source, this wouldn't be happening today (since there would not be a need for a game-activated workaround). Changing the name in QVFR only opens the door to it breaking when ED decides to use "Digital Combat Simulator" as the app name in the future. Always activating the workaround creates a maintainability issue where the workaround could potentially break non-DCS apps. 2) I don't have a code signing certificate today, so any release I'd make would break anti-cheat software (not in DCS, just ANY OpenXR game installed on your machine), which isn't something I'm going to do (cause then that is more fallout coming in my direction, for something that isn't even my problem). Acquiring a code signing certificate with Cloud Signing is >$1000 AND also several hours setting up a token vault and all of the other goodies that the digital government now requires. Not really sure what is the point of me spending hours of my time writing all this this stuff and explaining best practices and making detailed bug reports, pointing out issues, if this work just goes down the trash can without probably being read at all

Note that the bug is specific to ED'S multi-threaded code (they are submitting data from the wrong frame, a blantant violation of the OpenXR standard), so the ST version of DCS isn't affected (someone confirmed to me that it worked). Also, if you are on Varjo, you could disable Quad-Views-Foveated and instead use Varjo-Foveated, because that tool did not have the conditional check on the app name (unlike Quad-Views-Foveated, the Varjo-Foveated tool is pretty much only useful for DCS, so I never checked which app is running before activating the workaround).

I cannot release any new version because my signing certificate expired in February and the cost of digital signing has gone from $200 to >$1,000 in 2024, so I'm not getting a new one. I'm also real real real tired of repeating myself ED And specifically initial report point 2) here (March 2023):

See my reply here Same bug I reported to ED for >1 year but apparently no traction to fix it. They renamed the app so now the workaround doesn't kick in anymore.

@BIGNEWY this is the same bug I reported to you guys over a year ago, with incorrect FOV submissions in xrEndFrame(). There is a workaround to YOUR bug in Quad-Views-Foveated, but it looks for the application name being "DCS World", but it looks like you changed that string to "DCS", so the workaround doesn't kick in. Please fix the real issue anyway... your code is violating the OpenXR standard. Reported originally March 2023 with a very clear explanation (point 2):

That's the right answer, since the game one is done at the proper stage of rendering. I'll add for the streaming options (like Virtual Desktop) it's also nice to use the sharpening in the streaming app (done on the headset side) since it happens after the encoding+decoding, where some of the sharpeness was lost. Note that sharpening before the encoding will also increase bandwidth but it's quite necessary as it produces better results.

Better to ask on Varjo Discord, that's where Arch promised me it was going to happen.

The thing you need to understand is that quad views is going to **increase** your CPU utilization, regardless of FFR or DFR. That should be your primary concern. FFR vs DFR is a secondary concern and is more about how sensitive you are to peripheral view degradation. There is also the Pimax OpenVR FR, which will cost you no CPU, but will provide much smaller gains on the GPU. With this one there is 0 difference in performance between FFR and DFR. For short there is no "somebody please benchmark it for me", because too many variables. You can test out the impact of both quad views or Pimax OpenVR FR today by installing the Quad-Views-Foveated tool or the PimaxMagic4All tool respectively. You can configure the resolution to get close to what you'd get with the headset you are eyeing. This will give you a much better idea of what it will look like.

https://github.com/mbucchia/OpenXR-InstanceExtensionsWrapper/releases Varjo will be adding a toggle in their next release. Until then, the above is the hack.

You're being a little too pessimistic the Pimax API is stable and their PVR client is versioned in a way that older clients (such as PimaxXR) won't break on that front. Plenty of software works this way. It's been over a year now right (?) since last PimaxXR update, and nothing broke (EDIT: OK more like 8 months) the other day I heard someone on reddit getting DCS + QVFR working on a Varjo VR-1, that's software that hasn't been updated in years either. Same for WMR, I think I was the last person to push an update over a year ago, and it's still fine. Pimas has many incentives to keep PimaxXR working through their updates, since otherwise y'all would riot lol. Worse that can happen is some side effect or issue they can solve themselves in another update of Pimax Play, without even touching PimaxXR.

Probably not the next update (which is multi-monitor) but the one after that. One big challenge is unfortunately the incompatibility with many of the OpenXR tools out there like OpenXR Toolkit or OBSMirror and the lack of toggle in DCS for quad views... means it won't be enabled by default and require a user toggle in Virtual Desktop. Otherwise <profanity>'s gonna hit the fan if it's enabled by default.

Fwiw, I said it my other post "there is no indication they will support it in 1.1", but it's just a guess. We might might be pleasantly surprised. I highly doubt it though. Looks to me like they only care about standalone in their strategy (and unarguably there are good reasons for that). IMO best thing that would happen to us is them 100% abandoning Quest Link (as in: it's not available at all). This way something innovative and cared for, like Virtual Desktop, becomes the new standard and sets the bar. Virtual Desktop already has the features you want, without Developer Mode limitations. Virtual Desktop will soon have quad views support out-of-the-box without the need for any mod.

The news you've seen is about the OpenXR _standard_ being updated to 1.1. This is similar to something like "a new version of DirectX was released" - with either new or more integrated capabilities. Vendors will start rolling out new OpenXR runtimes - integrated to their platform - similar to how drivers would be updated for new DirectX version. Application developers (such as ED) have the opportunity to start using these new capabilities by writing new code. It's not likely to start happening before the roll-out phase above is in motion (which it isn't really today). End-to-end, a majority of the things announced for 1.1 were already possible in 1.0, such as the quad views foveated rendering that DCS already implements today. They are now more standard and slightly easier to use, but they still require efforts both on the platform vendors to implement (eg: Meta, the most important vendor, does not support quad views foveated rendering in 1.0 and there is no evidence yet that they will in 1.1) and the app developers to utilize (and thankfully ED does support quad views foveated rendering, if the platform supports it).

SteamVR has 2 levels of settings for a few of the options (include motion smoothing): the global setting and the per-game override. Have you double-checked that your per-game setting doesn't override motion smoothing to off specifically for DCS?

ED needs to fix this. Their lighting shaders are broken when using quad views, it's been like that for 18+ months unfortunately.

Sorry but no. There are so many completely wrong statements here. > DCS 2.8 stopped supporting OpenXR runtime and introduce their own version built in the game. No. DCS still supports OpenXR today. What changed is DCS MT defaulting to using OpenXR by default, instead of Oculus (OVR) and OpenVR by default. > Reason: Both OpenXR and DCS's runtime were active and working against each other. No. That doesn't make any sense. I think you do not understand what OpenXR is. > Now Meta Quest Link updates to 63.0.0 and no longer supports OpenXR and does not recognize the DCS version either. No. Quest Link still supports OpenXR, since it is the future standard going forward, and it's not going away any time soon.

My best guess is you have something else interfering, we know things like Ultraleap cause issues with DCS/OpenXR, there's probably more. I'd recommend you install OpenXR Explorer and inspect the list of API layers (center column, bottom part).

You're going to have to elaborate. With my thing, you should never see "Oculus" anywhere, so you probably re-enabled Oculus OpenXR after install. You can take a look at the log file under `%LocalAppData%\virtualdesktop-openxr` for clues. Given that this method has been working for others, it's likely that your issue wasn't OpenXR in the first place, but perhaps something completely different.