Problem RRRE VR in Linux 2026

Hi!
I have the mid to long term goal to migrate to Linux.

I have a partition with CachyOS running very well at the moment.
AMS2, AC, ACR (with UEVR) works rather well on VR with WiVRn, but I haven't manage to make the same with RRRE.

Works perfect on the flat screen with DXVK, but when it comes to VR I'm failing to find a way to translate the game's DirectX 9 output into something my RX 9070 XT can handle in VR.

I get the game running, but no video output on my headset (quest 2).
Though I can see that the video and the tracking works.

I also thought it was the Recenter VR view, or toggle screen function. But no. The only time I get an image is when I change from Borderless to windowed mode. I only get one frame an that's it.

I have tried also the OpenComposite workaround that I saw on the forums. Still no luck...


Anyone had luck to run VR in Linux?

And if so, how did you managed to do it?

 

Don't know if it can help, but for VR the game uses DX10. It generates frames in DX9 and then sends them to DX10 so that VR can work (DX9 doesn't support VR).

 

Thanks!
I will have a look, I was focusing on Protontricks workarorunds based on DX9
I think I will try Protontricks to install d3dx10 and d3dcompiler_47.
Maybe this could address the "bridge" and shader issues

But, since the game bridges DX9 to DX10 for VR, and my logs show a continuous RtlGrowFunctionTable loop during VR initialization, is there a specific DirectX 10 component or shader compiler (like d3dcompiler_47) that the bridge relies on which might be failing under DXVK/Proton?

That could explain why it only renders a single frame when I toggle windowed mode.

I keep digging and report what I find

 

Unfortunately that's all I know. Please post if you find anything, I'm curious too.

 

I spent a few hours with the help of AI to troubleshoot a bit more.
This are the findings so far:


Update — Full log analysis complete

After extensive troubleshooting I've managed to get proper Proton logs and analyse exactly what's failing. Sharing the findings here in case it helps anyone else trying VR on Linux, and so the devs have the full picture.

Setup: CachyOS Linux, Kernel 6.19.6, AMD RX 9070 XT (RDNA 4), Mesa 25.3.5 RADV, tested with GE-Proton9-19, GE-Proton10-32, and CachyOS-Proton 10.0. Headset: Quest 2. Tested both WiVRn/Xrizer and SteamVR.

Also — I found a misconfiguration on my end worth mentioning first

Every single session in my logs was launching the game with a duplicated -vr flag: RRRE64.exe -vr -vr 1.0. This was caused by Steam's built-in VR launch option already appending -vr, while I also had -vr 1.0 in my custom launch options. I'll be retesting with the corrected launch options, so some of what I describe below may change. That said, the core issues appear structural and not caused by the double flag.

WiVRn/Xrizer — two separate failures

The black screen in the headset is caused by two independent problems happening at the same time:

Problem 1 — Main 3D scene: Xrizer successfully negotiates a Vulkan-based OpenXR session with the game, but the game immediately closes it (SYNCHRONIZED → STOPPING → IDLE → EXITING) without ever submitting a frame. The Vulkan compositor path seems to be getting rejected by the game before rendering even begins.

Problem 2 — Overlay/HUD: The game's overlay system (menus, HUD) submits raw DirectX texture handles to Xrizer at framerate. Xrizer cannot process these and logs Unsupported texture type: DirectX continuously. This is a completely separate submission path from the main 3D scene, so even if Problem 1 were fixed, the HUD would still be invisible.

Tracking works fine throughout. It's purely a rendering/texture submission problem.

SteamVR — rendering thread hang

With SteamVR the texture error goes away, but the game's rendering thread enters an unrecoverable exception loop inside the game executable itself. The Proton logs show the game's own C++ exception handler (RtlRestoreContext at a fixed address in the game binary) firing continuously — consistent with a VR swapchain present failure that the engine can't recover from under Wine's SEH emulation. This produces the "one frozen half-frame" symptom, and Alt+Enter forces a single buffer flush which is why toggling windowed mode produces exactly one more frame before freezing again.

Question for the devs / anyone with more knowledge:

1. Is there a known reason the game would immediately close a valid Vulkan OpenXR session without submitting frames? Could this be the DX9→DX10 bridge bypassing the OpenXR submit path entirely?
2. Is there any way to force the overlay compositor to submit Vulkan-compatible textures rather than raw DirectX handles?
3. Has anyone on the team looked at Proton VR compatibility, or is this something that would need to come from the community side?

Happy to share the full logs if useful. Will update once I've retested with the corrected launch options.

 

You must love self-inflicted pain. It's already difficult to get VR working perfectly with sims designed for Windows in the first place, now you are trying to push your luck and getting everything to work perfectly with an O/S used for gaming for less than 3% of gamers, even less for sim racing. Good luck.

 

I cant even get stable framerate with R3E on a 5090 in windows.. interested to see how you go in linux..

 

can you share your full specs and your nvidia control panel settings

Andi

 

Lol 100% true!
But I love RRRE, It does works quite well in VR for me on Win11, and it does also runs really well on Linux in DXVK on a flat screen.
So I was checking if there was a window of opportunity to get Raceroom fully running in Linux before a DX12 update.

 

Thanks Thomas!
At least I had to raise the issue, and see if I could get some traction of some members of the Community.

The game runs really well on Linux when playing on the screen with the DXVK. So if someone is curious of testing some Linux Distro, and you play on a single screen you would be fine.
So I was hopeful that could be a way to also fix the VR implementation. But I understand that you have limited resources.

Thanks for pointing a possible fix with the RBR implementation. I will have a look now
Lets see, maybe its time for me to learn some new skills

 

My specs are in my signature

At risk of repeating this issue in a non related thread (my fault) a long and well detailed journey of many users issues in the regard already exists:

the short version is no matter what tricks and crazy workarounds like process lassoo custom dll's etc we try, stutters and microstutters abound.. this started happening after the last major graphical update that introduced PBR.

In all of that the gpu and cpu are consistently only at 30-40% usage. so its not a hardware issue, ample headroom.. For reference I can run ACE on ultra settings stable at 72fps ad 3X superresolution.. im struggling to maintain that framerate on r3e even at low settings ("vr preset"), and 1X resolution.

 

With the newest version of Monado which removes the need to use SteamVR, I feel like I'm getting an okay experience with VR under Linux with my Bigscreen Beyond and a 9070XT.

Setup Instructions for Arch
Install envision-xr-git, monado-git, xrizer-git, and wayvr-git from AUR
Start Envision
Under the burger menu, enter preferences, go to plugins, and enable WayVR
Put headset on floor in middle of playspace facing front
Click calibrate
Wait a few seconds
Start Monado
This should get you a working Monado profile with lighthouse based tracking

In Steam, add the following launch options to RRRE
PRESSURE_VESSEL_IMPORT_OPENXR_1_RUNTIMES=1 %command%

Launch RRRE in SteamVR mode

This should get RRRE running without SteamVR.

In graphics options, make sure antialiasing is disabled.

There might be a few more things that I'm forgetting here, but this should get you most of the way there I think.

Ask away if you have any questions that need clarified.

Now to improve my terrible lap times.

 

I was on Holidays until today.
I will try it and report later.


Thanks for the suggestion