@rbernon I expect you are already aware that 32bit OpenVR is broken in Proton 10 (VR_Init crashes), but CC just in case.
I did a bisect and it broke somewhere between proton-10.0-1b and the commit immediately following proton-9.0-4d.
I have been, unfortunately, not able to track it down closer than that as none of the intermediate commits will build for me.
Figured out that while I could not test the entire intermediate versions as they would not build, I could test just the vrclient_x64 portions by checking them out into nearby complete versions that did build.
Bisecting this way identified the problem commit as 454533f7e3964a25e787ef8910a81244a686d0f0. This commit changed the calling convention of VRClientCoreFactory and HmdSystemFactory from CDECL to __stdcall.
Reverting this commit on the head of the Proton_10.0 branch makes calling VR_Init work in 32bit mode again. 64bit continues to work as well, and I also tried a full 32bit VR program, and that works too.
CCing @bylaws as the author of the commit.
@twhitehead Do you have an example game that uses this? Thank you for all the details and investigation so far :)
Condor 2 and 3 are both examples. I use them via Revive under Linux as they internally use the Oculus VR API.
You don't need anything fancy to see this bug though. Any 32bit OpenVR application should be broken. You can't even successfully call VR_Init as can be seen by compiling and running this bit of code
#include <stdio.h>
#include <openvr.h>
int main() {
vr::EVRInitError error = vr::VRInitError_Init_NotInitialized;
vr::IVRSystem* ptr = vr::VR_Init(&error, vr::VRApplication_Scene);
printf("ovr_Initialize(...): returned error %d and object %p\n", error, ptr);
vr::VR_Shutdown();
return error; // vr::VRInitError_None == 0
}
Dug into this a bit. Here are the details. Patch is following shortly.
The VRClientCoreFactory function is declared in the OpenVR SDK without a calling convention. According to Microsoft cdecl is the default calling convention for C and C++ functions, so this means that the user side needs VRClientCoreFactory to be cdecl and not stdcall.
In more detail, if the system side is stdcall (callee cleans stack), it is going to pop the arguments off the stack before returning. Then the client side is then going to do the same as it thinks it is cdecl (caller cleans stack). Obviously this ends badly as exhibited by the simple program above that just calls VR_Init.
The reason this only affects x86 code is these calling conventions only exist for x86. For x64 code they are simply ignored. See here for cdecl
On ARM and x64 processors, __cdecl is accepted but typically ignored by the compiler
and here for stdcall)
On ARM and x64 processors, __stdcall is accepted and ignored by the compiler
There is also a vrclient_x64.spec file checked in on the original commit that is currently declaring both of these to be stdcall too. Changing this to cdecl gets rid of the the following linker warnings
ld: warning: resolving _HmdSystemFactory@8 by linking to _HmdSystemFactory
ld: warning: resolving _VRClientCoreFactory@8 by linking to _VRClientCoreFactory
Apart from these warning, it seems these misdeclarations were not causing any issues as HmdSystemFactory does not appear to be used at all and VRClientCoreFactory is only called by the OpenVR SDK which accesses it directly by manually opening the dll, looking up the symbol, and assigning it to a cdecl function pointer.
@twhitehead Thank you! A fix just got pushed to the experimental-bleeding-edge in addition to reverting the problematic change. There is already a build available if you select the bleeding-edge beta option in the Proton - Experimental tool properties. However - coincidentally there is another regression that was just introduced in dxvk yesterday which we found while testing the fix for this regression, so your milage may vary depending on which games you are trying to play until that gets fully resolved, hopefully in the next day or two :)
Thank you again for the report and for all the details and investigation!
@twhitehead The secondary regression has now been fixed in experimental-bleeding-edge. Please let me know if you are still seeing a regression with any 32-bit openvr titles :)
Comes up fine now. Thanks very much. I'll close the ticket. 👍
proton 10.0x2 2025-06proton 10.0-1bx1 2025-06proton 9.0-4dx1 2025-06rpcrt4.dllx1 2025-05setupapi.dllx1 2025-05vrclient.dllx1 2025-05vrclient_x64.dllx1 2025-05winevulkan.dllx1 2025-050xc0000005x1 2025-05
When
VR_Initis called from a 32bit Windows binary on a 64bit Linux machine, it either crashes or returns a huge number for the error code and 0 for the API table.Here is a simple program that just calls
VR_Init. Here is the trace in 32bit mode (this one died)and here it is in 64bit mode (this one is fine)