[Bug]: UEVR + WiVRn works when launched manually, but fails when launched from Bottles GUI

Describe the bug

UEVR + WiVRn works correctly when the same Windows game is launched manually using Soda 11.0-10 with the same Wine prefix and the environment variable SODA_OPENXR_RUNTIME=host.

However, when the same game and UEVR are launched from the Bottles GUI, UEVR fails with:

OpenXR not loaded: could not create openxr instance: -51 OpenXR not loaded: openvr_api.dll not found

The important point is that the underlying WineOpenXR + WiVRn stack is functional. With the manual launch method, UEVR injects successfully and the actual game reaches an active OpenXR session on the Pico 4 Ultra, including xrWaitFrame, xrBeginFrame, xrLocateViews and xrEndFrame.

Adding SODA_OPENXR_RUNTIME=host to the bottle environment in Bottles does not reproduce the working behavior when launching from the Bottles GUI.

To Reproduce

1. Use a 64-bit Unreal Engine game compatible with UEVR.
2. Use Bottles 67.3 Flatpak with Soda 11.0-10.
3. Configure WiVRn as the active Linux OpenXR runtime.
4. Use a single Wine prefix containing both the game and UEVR.
5. Add the required HKCU\Software\Wine\VR OpenXR Vulkan registry values.
6. Add SODA_OPENXR_RUNTIME=host to the bottle environment.
7. Launch the game from the Bottles GUI.
8. Launch UEVR from the Bottles GUI.
9. Select the running game and attempt injection.

Expected: UEVR should detect the game and initialize OpenXR through WineOpenXR → host OpenXR runtime (WiVRn).

Actual: UEVR reports XR_ERROR_RUNTIME_UNAVAILABLE (-51) and the OpenVR provider also reports openvr_api.dll not found.

The same prefix, runner, game, UEVR installation and OpenXR configuration work when the game and UEVR are launched manually through the same Soda runner with SODA_OPENXR_RUNTIME=host.

Package

Flatpak from Flathub

Distribution

Kubuntu 26.04.1

Debugging Information

Bottles: 67.3
Package: official Flathub Flatpak
Runner: Soda 11.0-10
Desktop: KDE Plasma
Session: Wayland
GPU: NVIDIA GeForce RTX 5070 Ti 16 GB
NVIDIA driver: 595.91.07
VR runtime: WiVRn
Headset: Pico 4 Ultra
UEVR: current installation used for the test

The same Wine prefix works when launched directly with the Soda runner and:
SODA_OPENXR_RUNTIME=host

Linux OpenXR active runtime:
~/.config/openxr/1/active_runtime.json
-> /usr/local/share/openxr/1/openxr_wivrn.json

Vulkan:
vendorID = 0x10de
deviceID = 0x2c05
deviceName = NVIDIA GeForce RTX 5070 Ti

Troubleshooting Logs

Failing launch from Bottles GUI:


info:    OpenXR
Loaded L"C:\\windows\\system32\\wineopenxr.dll" ... builtin
trace:openxr:__wineopenxr_GetVulkanInstanceExtensions
err:openxr:get_vulkan_extensions Could not query value, status 0x2.
trace:openxr:__wineopenxr_GetVulkanInstanceExtensions could not initialize openxr: -6
trace:openxr:__wineopenxr_GetVulkanDeviceExtensions
err:openxr:get_vulkan_extensions Could not query value, status 0x2.
trace:openxr:__wineopenxr_GetVulkanDeviceExtensions could not initialize openxr: -6


After manually providing the expected `HKCU\Software\Wine\VR` values, the same WineOpenXR implementation successfully initializes when launched directly through Soda.

Successful manual initialization:


trace:openxr:wine_openxr_init_once g_device_extensions VK_KHR_dedicated_allocation VK_KHR_external_fence VK_KHR_external_memory VK_KHR_external_semaphore VK_KHR_get_memory_requirements2 VK_KHR_image_format_list VK_KHR_external_memory_fd VK_KHR_external_semaphore_fd VK_KHR_external_fence_fd.
trace:openxr:wine_xrGetVulkanInstanceExtensionsKHR returning: VK_KHR_external_fence_capabilities VK_KHR_external_memory_capabilities VK_KHR_external_semaphore_capabilities VK_KHR_get_physical_device_properties2 VK_KHR_surface VK_KHR_win32_surface
trace:openxr:get_extensions Got required instance extensions: VK_KHR_external_fence_capabilities VK_KHR_external_memory_capabilities VK_KHR_external_semaphore_capabilities VK_KHR_get_physical_device_properties2 VK_KHR_surface VK_KHR_win32_surface
trace:openxr:get_extensions Got required device extensions: VK_KHR_dedicated_allocation VK_KHR_external_fence VK_KHR_external_memory VK_KHR_external_semaphore VK_KHR_get_memory_requirements2 VK_KHR_image_format_list VK_KHR_external_memory_fd VK_KHR_external_semaphore_fd VK_KHR_external_fence_fd
trace:openxr:wineopenxr_init_registry Got XR extensions.
trace:openxr:wineopenxr_init_registry Initialized OpenXR registry entries


With the manual launch method, the actual game process successfully reaches an active OpenXR session:


trace:openxr:thunk64_xrWaitFrame
trace:openxr:thunk64_xrBeginFrame
trace:openxr:thunk64_xrLocateViews
trace:openxr:thunk64_xrLocateSpace
trace:openxr:thunk64_xrGetActionStateVector2f
trace:openxr:thunk64_xrGetActionStateBoolean
trace:openxr:xrEndFrame
trace:openxr:xrPollEvent


The working manual launch uses the same Wine prefix and Soda 11.0-10 runner as the Bottles GUI launch, with:


SODA_OPENXR_RUNTIME=host


Therefore the same WineOpenXR/WiVRn stack is functional when launched directly, while the Bottles GUI launch fails during OpenXR initialization.

Additional context

The issue does not appear to be a general incompatibility between UEVR, WineOpenXR, Soda or WiVRn.

WiVRn is the active Linux OpenXR runtime and works correctly with the Pico 4 Ultra. Vulkan correctly detects the NVIDIA GeForce RTX 5070 Ti.

WineOpenXR in Soda 11.0-10 also works correctly. A native PE64 test program running inside the same Wine prefix can call wineopenxr_init_registry(), obtain the required Vulkan OpenXR extensions from WiVRn, and initialize the OpenXR registry entries successfully.

The relevant registry key is:

HKCU\Software\Wine\VR

with the following values:

openxr_vulkan_instance_extensions
openxr_vulkan_device_extensions
openxr_vulkan_device_vid
openxr_vulkan_device_pid

The detected GPU IDs are:

vendorID = 0x10de
deviceID = 0x2c05

The working manual launch uses the same Wine prefix and the same Soda 11.0-10 runner as the failing Bottles GUI launch, together with:

SODA_OPENXR_RUNTIME=host

With this manual launch method, UEVR successfully injects into the game and the actual game process reaches an active OpenXR session. The Pico 4 Ultra displays the game correctly and the log contains calls such as xrWaitFrame, xrBeginFrame, xrLocateViews, xrLocateSpace and xrEndFrame.

When the same programs are launched from the Bottles GUI, OpenXR initialization fails with XR_ERROR_RUNTIME_UNAVAILABLE (-51).

Adding SODA_OPENXR_RUNTIME=host to the bottle's environment variables does not reproduce the working manual behavior.

This strongly suggests that the underlying WineOpenXR/WiVRn configuration is functional, but that the Bottles GUI launch path does not reproduce the same runtime environment or initialization state as the direct Soda launch.

I am using the official Flathub package of Bottles and am not using SteamVR, ALVR or another VR runtime. The intended OpenXR path is:

Windows game → UEVR → WineOpenXR → Linux OpenXR loader → WiVRn → Pico 4 Ultra.

The working manual configuration is currently used as a workaround.