Reverb G2 VR HMD is unable to be driven at the full display bandwidth presumably due to a displayport lane limitation max of 2 in the Nvidia driver instead of the full 4 needed but this is speculation.
Users of Monado and SteamVR must select the 60Hz mode or the display remains black, the 60Hz mode is also extremely prone to flicker due to the slow rates which is quite a poor experience.
To reproduce start Monado with the env var "XRT_COMPOSITOR_FORCE_NVIDIA_DISPLAY=“HP Inc.” to select the Reverb G2 as the VR display and notice how the display remains black due to the default being the 90Hz mode.
Now use XRT_COMPOSITOR_PRINT_MODES=1 to dump the available modes into terminal and select an index next run with XRT_COMPOSITOR_DESIRED_MODE of 60Hz and the HMD should now operate.
For comfortable operation the driver should be able to push 90Hz to the display.
I’m seeing the same behavior for HP Reverb G2 (60 Hz work, 90 Hz doesn’t) with RTX 5070 Ti as well.
I’m not sure if the bandwidth / number of lanes is the main factor as 2880x1440 @ 90 mode also doesn’t work. I assume that if the problem was just the bandwidth, then given 4320x2160 @ 60 mode works, the 2880x1440 @ 90 mode should have worked as well (as it requires even less bandwidth) but that’s not the case.
As mentioned in the posts above, this makes the headset basically unusable for any “real-world” scenarios due to extreme flickering, so either the fix or any suggestions on the work-arounds would be appreciated!
Same problem here. It would be nice to get this working in Linux since it had no problems with Windows drivers for years. 60Hz is too low and induces headaches.
We are tracking the “display remaining black on the Reverb G2 at 90 Hz” issue on an internal bug 5923212. We can reproduce the failure, and it is under investigation.
Is there an older NVIDIA driver version where this did not occur?
It seems that to the knowledge of folks I’ve chatted to in Linux VR adventures and Monado discord servers, no GPU, with any historical driver has ever worked above 60Hz.
Following up here — I ran a full factorial that isolates refresh rate, vertical blanking, and
pixel clock as independent variables on real hardware (physical verification every time,
headset worn, not just API success), plus identified the bridge chip’s own datasheet ceiling.
Posted the full results (table, methodology, bridge chip data, an open question about the
ANX7530’s PLL) as a follow-up in a related thread I’d started for a different EDID issue on
the same headset, to avoid fragmenting the data across two threads further
Short version: none of resolution, refresh rate, vblank duration, or total DisplayPort
bandwidth alone explain the failure — the only pixel clock that has ever produced an image,
across every combination tried, is exactly ~709.15 MHz (the bridge chip’s own native
4320x2160@60 timing). That, plus the bridge chip’s datasheet (“DisplayPort Receiver Input
Bandwidth supports up to 4K x 2K x 60Hz” as an explicit spec line), points at a
hardware/firmware ceiling rather than a pure EDID/mode-timing problem. @abchauhan
Any update on bug 5923212 from your side? It’s been quiet since March
Update on my factorial results above: they’re superseded — 90 Hz does light up now, and I
found exactly why the factorial never showed it.
Short version: every test in that factorial (and the native-mode result I’d cited before it)
either predates a separate bug I later found and fixed (NVKMS clamps color depth to 6 bpc
when this EDID leaves it undeclared), or used a synthetic/injected timing rather than the
panel’s plain, unmodified native mode. Nobody had retested the literal native EDID timing
with that patch actually in place until today - and it lights up fine.
The bridge-chip-ceiling conclusion from the factorial doesn’t hold up - once the bpc bug is
patched, native 90 Hz (the exact same EDID timing, unmodified, byte-identical to what Windows
itself uses per a CRU capture) lights up fine. There’s still an open question about a visible
flicker at 90 Hz even with a real image now, detailed in the other thread, so I’m not calling
this fully closed - but the “90 Hz is architecturally impossible on this link” conclusion I
posted earlier was wrong, and I wanted to correct the public record here rather than leave it
standing.
EDIT (same day): the visible-flicker caveat above is resolved. It turned out to be partly
an artifact of my own test pattern (it alternated colors every frame — i.e. it strobed by
construction), and the one remaining genuine observation cleared after a reboot plus
re-seating the headset’s USB, with zero driver-side changes in between. Retested with a
static solid white at all three modes: both 90 Hz modes are clean; 60 Hz shows the same
flicker this headset also shows on Windows at 60 Hz (the panel’s own backlight behavior at
a non-native rate, not a driver issue). Details in the 379240 thread linked above. So:
with the bpc patch, native 90 Hz is fully working and visually clean — the original
problem this thread is about is, as far as I can verify, completely solved on 595-open.
We’ve confirmed the patches available in nikolai.viktorovich’s repo do fix the issue and were able to get a reverb G2 display to init to plasma desktop in the display at 90Hz on NVIDIA.
Please take a look at these if you have not already!
Great to hear it’s confirmed working on your end too — thanks for testing and reporting back. Now that there’s independent confirmation beyond my own hardware, I’ll also flag this to the LVRA wiki folks, since the hardware compatibility page still has a stale G1-era note that doesn’t reflect this
