EDVR 0.20.2: Elite Dangerous VR Patch Restores AA, HUD Glow and the Oculus Route

By Indie Kings | October 22, 2026

Updated October 22, 2026: EDVR, the unofficial VR patch for Elite Dangerous: Odyssey, published 0.20.2 on 22 October 2026, a day after 0.20.1. Both are patch releases. Between them they restore an Oculus route displaced by the project's own deadlock bypass, and fix doubled HUD bloom and depth of field plus anti-aliasing that had stopped being applied in three places.

Image: GitHub repository card for characterecho-sean/edvr-unofficial-patch, the unofficial VR patch for Elite Dangerous.

What EDVR is, and why patch releases matter here

EDVR is an unofficial patch that gives Elite Dangerous: Odyssey DLSS, FSR and XeSS upscaling in VR, plus a couple of dozen fixes for problems that make the game uncomfortable in a headset. It is a native OpenXR package, installed in about three minutes by a single executable, and it is free.

It is also, by necessity, a patch that sits between the game and the graphics stack. That position is what makes 0.20.1 and 0.20.2 worth reading. Version 0.20.0 was a large release: one installer for both editions, a new Elite build to support, and a bypass for a deadlock in Elite's LoadLibrary path. One of the bugs that followed was a direct consequence of that bypass, and the notes trace it precisely.

The build context matters. 0.20.0 was the first release built and checked against Elite build 334473, the Anaconda Mk II Update, version 4.4.2.0. The installer refuses Elite Dangerous (Horizons) and refuses an unreadable executable before it writes anything. An Odyssey revision it was not checked against installs with a warning, and in that case the fixes tied to the game build stand down, with the graphics log naming each one.

The Oculus route that the deadlock fix displaced

The 0.20.1 notes describe a regression with a clean cause. Version 0.20.0 release candidate 3 added a bypass for a deadlock in Elite's LoadLibrary path. That bypass hooked the same import slot that EDVR's own Oculus route uses. On the Oculus PC runtime, Elite's load therefore skipped EDVR's route entirely and ran on Elite's native Oculus back end, which is a different renderer with different behaviour.

The fix passes Elite's load through EDVR's route first, then lets the bypass run. It is a small change and a good illustration of the risk in this kind of patch: two hooks in the same process competed for one slot, and the newer one won silently. Nothing crashed. The patch simply stopped doing its job for one class of user.

That is the failure mode worth naming, because it is invisible from the outside. A user on the Oculus PC runtime would see Elite start, VR work, and EDVR's upscaling and fixes not take effect, with no error to search for. The release notes now ask anyone reporting a problem on that runtime to say so, which is how the report was classified in the first place.

Doubled bloom, doubled blur and a crisp HUD check

Two more 0.20.1 fixes come from the same layer. With Bloom on and a temporal mode active, the HUD layer was adding Elite's bloom to itself a second time, and on the System Map star halos were up to about twice as bright as they should be. With Depth of field on, the HUD layer was adding the scene's blur a second time as well.

The bloom fix is part of fix.ui_quality, which is the setting EDVR uses to draw the interface at a different resolution from the world; the notes do not tie the depth-of-field fix to a setting. That is a plausible place for a double application: the HUD is composited separately, and a pass that reads the scene's lighting or blur and does not know it is the HUD will apply it twice if it runs once per layer.

The third 0.20.1 fix is a compatibility one. Crisp HUD validation checks which pixels are covered, and it now accepts D3D11 devices that another tool has wrapped. That came from a community pull request, number 119, and it matters because EDVR explicitly supports running alongside EDHM and ReShade, both of which can wrap the device.

The 0.20.2 release then restored the other half of the same feature. The cockpit HUD's glow had gone missing with interface quality on, because the HUD layer had taken its light out of the game's bloom input. That light now feeds the bloom again, so engine pips and similar HUD elements show their halo. The light is weighted by the area each pixel covers, so a thin HUD stroke no longer changes its halo brightness depending on which columns it falls in.

The anti-aliasing that was refused every frame

The 0.20.2 notes spend most of their detail on anti-aliasing, and the pattern in all three cases is a guard that rejected a frame it should have accepted.

Where the AA was lost	Cause in the notes	What changed
Flat supercruise	The deferred lighting camera is repaired when the game gives it no jitter phase at all, so every frame with a phase was refused and the temporal history reset each frame	The camera is repaired in that case, so the history survives
Loadout screen and suit preview	A scene lit by a verified lighting pass was counted only at certain draw counts, so the suit preview was refused	The scene now counts at any draw count
Loading screen at Supersampling 0.5	The hologram frame was refused every frame, so the game's bilinear stretch showed instead	SMAA and EASU now run on that frame

The supercruise case is the clearest of the three. A temporal anti-aliasing pass needs a jitter offset per frame, and it needs that offset to change, because the history it accumulates depends on the camera moving by a subpixel amount. The guard was on the wrong side of that requirement: frames that carried a phase were refused and the history was reset every frame, while a camera with no phase at all was left unrepaired. The fix repairs the camera in the no-phase case and stops refusing the frames that have one.

The loading screen case is the one most people will notice, because Supersampling 0.5 is the setting you use when you want the interface crisp but the world cheap. Losing AA there means the loading screen is the one screen in the game that looks worse than everything around it.

There is also a smaller fix in the same release for fleet carriers: in optimized stations, bay door pieces that contain the camera at the pad no longer drop out. That is the kind of clipping bug that only appears when the camera is placed exactly where a piece of geometry expects it not to be.

Two interface quality choices and a new AA model list

The releases add two values to an existing setting and replace a list of options in another, which is the sort of change that silently breaks configs if it is handled badly.

Setting	Accepted values	Default and migration
`fix.ui_quality`	`off`, `100`, `125`, plus `150` and `200` for 1.5 and 2 times the display size	Default is still `100`; the new values are opt-in
`fix.temporal_aa_model`	`K`, `L`, `M`	`K` is the default; `J`, `responsive`, `auto` and `default` are removed, and an `edvr.ini` that still names one of them runs `K` and says so once in the log
`advanced.glare_shader_dump`	Diagnostic setting	Now read from `edvr-flat.ini` in the desktop edition, where it had been ignored

The migration line is the important one. Removing a value that users have in their configuration file usually produces either a silent fallback or a crash; EDVR's notes commit to the fallback plus one log line, which is how it should be done. The two new interface quality levels also answer a real complaint, since 125 percent is a compromise and 150 or 200 is what you want if you are willing to pay for a sharper HUD with DLAA or temporal anti-aliasing.

The notes also record a removal that never shipped. A sun-skip A/B key was added during the release cycle and removed again before release. Publishing that is a small honesty signal: the feature list is the final state, not everything that was tried.

The Linux installer that could not confirm a stopped game

One fix in 0.20.2 has nothing to do with rendering. The Linux installer refused to run from host Python because its check for a stopped game was Windows-only, and the check could never confirm that Elite had stopped. The check now reads /proc, and the installer still refuses while Elite is running, whatever the target.

That is a narrow fix for a narrow audience, and it is worth noting because of what it says about the project's scope. Elite Dangerous is a Windows game, and EDVR is a Windows graphics patch. The Linux path exists for installing a Windows game under a compatibility layer, which means the installer has to reason about processes it does not own. Getting that check wrong in the safe direction, by refusing to install, is the right failure, and it is why the bug was reported as an annoyance rather than as data loss.

Unofficial, unsigned and running inside a live game

Our take: the engineering is careful and the structural risks are unchanged.

EDVR is not affiliated with Frontier Developments, and it patches a live online game's executable at load time. Frontier's terms on third-party tools are the user's decision to make; we are reporting on the release, not advising anyone on their account. The safest reading is the one the project itself takes: it supports the game builds it names, it warns when it does not recognise a revision, and the fixes tied to a build stand down rather than guessing.

The installers are unsigned, and Windows will warn about them. The notes publish SHA-256 hashes for each installer, for the files inside the zips, and for the zips themselves, alongside a SHA256SUMS file. That is the correct minimum for an unsigned binary that writes into a game folder, and it is still only an integrity check, not a statement about who built the file.

The runtime warning matters as much. EDVR needs the Windows active OpenXR runtime set to the one you intend to use, and it explicitly says not to install OpenComposite or a vendor OpenXR loader to make it work. The README's field checks cover Pimax over PiOpenXR, Quest 3 over Virtual Desktop's VDXR and Air Link, and it claims nothing for other headsets or runtimes. If your headset is not in that list, you are the test case.

FAQ

What does EDVR 0.20.2 fix?
Anti-aliasing that was lost in flat supercruise, on the loadout screen and on the loading screen at Supersampling 0.5; the cockpit HUD glow with interface quality on; carrier bay door pieces dropping out; and the Linux installer's stopped-game check.

What did 0.20.1 fix?
The Oculus PC runtime route, which a deadlock bypass had displaced; doubled HUD bloom and doubled HUD depth-of-field blur; and crisp HUD validation on wrapped D3D11 devices.

Why did the Oculus route break?
The bypass added in 0.20.0 release candidate 3 hooked the same import slot as EDVR's Oculus route, so Elite's load skipped the route and used its own Oculus back end.

What are the new interface quality values?
fix.ui_quality now accepts 150 and 200 for 1.5 and 2 times the display size, in addition to off, 100 and 125. The default remains 100.

Do old configurations still work?
Yes. If fix.temporal_aa_model names a removed value such as J, the patch runs K and logs that once.

Is EDVR official or endorsed?
No. It is an unofficial patch, not affiliated with Frontier Developments, and its installers are unsigned. Check the published hashes and accept that any third-party tool used with an online game carries account risk.

Bottom Line

Two patch releases in two days, and both are about the same thing: 0.20.0 was a large change to how EDVR hooks Elite, and the bug that followed most directly from it was self-inflicted. A deadlock bypass took the import slot its own Oculus route needed, so one class of user ran without the patch. Separately, the HUD layer applied the scene's bloom and blur a second time, which doubled both, and three anti-aliasing guards refused frames they should have accepted, the worst of them resetting the temporal history every frame in flat supercruise, where the shimmer is most visible. The fixes are precise and the notes explain the cause rather than just the symptom, which is what makes them worth reading even if you do not fly in VR.

The additions are smaller but real: interface quality at 150 and 200 percent for a sharper HUD, a three-model list for temporal anti-aliasing with a graceful fallback for old configs, and a restored HUD glow that is now weighted by pixel area. The Linux installer's /proc check is a niche fix done in the safe direction. What has not changed is the structural position: an unsigned, unofficial patch hooking a live online game, supported only on the game builds and VR runtimes it names. Use the published hashes, stay on a build EDVR recognises, and read the log after a patch release, because the failure mode in this project is silence rather than a crash.

Sources

EDVR repository README, characterecho-sean/edvr-unofficial-patch, accessed 22 October 2026
Release notes for v0.20.2 and v0.20.1, published 22 and 21 October 2026
Release notes for v0.20.0, published 20 October 2026, for Elite build 334473
GitHub repository metadata for characterecho-sean/edvr-unofficial-patch, accessed 22 October 2026