search

LibreVR / Revive

Play Oculus-exclusive games on the HTC Vive or Valve Index, scroll down for downloads and installation instructions.
Other
3.6k stars 332 forks source link

Linux #1571

Open Patola opened 4 years ago

Patola commented 4 years ago

Is there any way to get revive running on Linux? Valve Index works on Linux perfectly through SteamVR. Which now offers OpenXR. But I'd like to play Asgard's Wrath and other oculus-exclusive games. And I will not sign the Microsoft EULA and install Windows.

fholger commented 4 years ago

Can you even install the Oculus runtime and get it running through Wine? If not, then that's already a show stopper. If yes, you could try to install one of the free games from the Oculus store and then run the ReviveInjector.exe manually through Wine.

I'd say chances are slim, but depending on which step breaks, there may or may not be options.

Patola commented 4 years ago

Oh. I see... Tried both the legacy runtime and the newer one. Didn't even install...

fholger commented 4 years ago

Then I'm afraid, until Oculus decides to support Linux as a platform, there's nothing to be done...

BoofOof32 commented 1 year ago

it's a shame not much can be done here. I'm very interested in seeing Oculus Rift games working on Linux someday. There's not much I can do feasibly by myself, but I could at least get a conversation going on what hurdles would need to be overcome to make Rift games a possibility.

So it's already established that the lack of a runtime is an immediate non-starter, so a few solutions may come to mind. Either... A.) the Oculus Runtime is reverse engineered somehow B.) the games are tricked into running on a different runtime (like Monado perhaps)

Honestly I'm mostly spitballing ideas, of course neither of these would be easy, but I thought I'd get the conversation going. Some feedback or responses would be appreciated 🙂

CrossVR commented 1 year ago

(B) Is exactly what Revive does by translating Oculus SDK calls to OpenVR or OpenXR.

Proton already has support for OpenVR and OpenXR. And since you can theoretically run Revive under Proton it doesn't need a Linux port.

Your main obstacle is getting the Oculus store to work, but Steam has some Oculus exclusives itself. So all that's needed is for someone to try it.

ShadowJonathan commented 1 year ago

Has anyone tried running revive under proton, and successfully downloaded and launched a game from the oculus store using that?

BoofOof32 commented 1 year ago

I might be onto something.

So I got SteamVR installed and ALVR going, now onto Revive. I added the installer as a Non-Steam game, ran through proton, which then installed Revive into it's own prefix in ~/.steam/steam/steamapps/compatdata/2539255137/pfx/. I then went to the properties of the installer and redirected the target to ReviveOverlay.exe. To my surprise, doing that made the Revive icon appear on the dashboard in SteamVR. Screenshot_20221002_181503

Now of course it can't find any Oculus games, as the Oculus Launcher isn't installed, so I yanked Lone Echo from my Windows drive and tried to see if I could inject it. Screenshot_20221002_181230 I'm not super surprised as there's no Oculus SDK to really initialize.

I have one more idea, and that is to copy my entire Oculus install into Revive's Proton prefix in the hope that it'll detect the installed games, but otherwise, I'm not sure what else I could do here.

I'll be back to report my findings

BoofOof32 commented 1 year ago

alright, so unfortunately, taking my Oculus Launcher install and putting it into the same prefix as Revive didn't really change anything :slightly_frowning_face:. The games didn't appear on the dashboard, and injecting still doesn't do anything.

I'd love some more ideas or suggestions, but I'm not quite sure what else I could do.

CrossVR commented 1 year ago

@BoofOof32 Simply copying the Oculus launcher install won't work, because the Oculus runtime will not have installed correctly. Try actually installing the Oculus Store in the same prefix as Revive. Though I'm not sure if running Oculus Store games will even work under wine, because it needs a background service running for platform functionality like entitlement checks.

It's probably easier to start with a Steam game that only has Oculus SDK support if you have any of those. All you need then is the xinput proxy, the Revive DLL and a wine DLL override. I've started an appveyor build that includes the xinput proxy, I'll add some instructions for this part later. Do you have an Oculus-only title in your Steam library?

BoofOof32 commented 1 year ago

I would try installing the Oculus launcher, however, there's still some bugs in Wine that would need to be resolved before that's feasible. There's a workaround to bypass the error that there's "not enough disk space", but after a few GB in, it errors out in another way

I'm digging around for Oculus only titles on Steam, but they're hard to find, and I don't have any on me. If someone could link a game like that (ideally free or cheap), that'd be appreciated

BoofOof32 commented 1 year ago

also, i just realized that latest commit didn't build successfully in Appveyor, strange

CrossVR commented 1 year ago

Yeah my bad, forgot I deleted the xinput proxy at one point. Anyway might be better to try a standalone Oculus app then? You can just run that using the injector.

For games from the Oculus store you'll indeed need to wait for Wine to fix it, there's nothing for Revive to do there.

BoofOof32 commented 1 year ago

Ok, so I did manage to find one Oculus only SteamVR game, that being DiRT Rally. Even though It's "VR supported" according to Steam, however it doesn't appear as one in my actual library.

I made sure to run the Windows version of DiRT Rally, and when I'm VR, it will only run in standard flatscreen mode. Injecting it with Revive didn't seem to do really do much, in fact, it didn't even open the game. Scrounging around the games files, I see no mention of anything VR or Oculus related, so I'm wondering why the store page said it supported it to begin with. I may be missing a step potentially.

CrossVR commented 1 year ago

Ok, so for that one you'll need to install Revive 2.1.1 and follow these instructions: https://github.com/LibreVR/Revive/wiki#standalone--steam-games-alternative

Make sure to follow the 32-bit instructions as Dirt Rally is a 32-bit game.

BoofOof32 commented 1 year ago

hmm, I'm not sure what I'm doing wrong. I gave the game the 3 DLLs mentioned above. But I'm still not having any luck with it. Whether I'm starting from Steam or injecting again :/

CrossVR commented 1 year ago

My bad, forgot to mention you need to add this to the launch options for Dirt Rally in Steam:

WINEDLLOVERRIDES="xinput1_3=n,b" %command%

BoofOof32 commented 1 year ago

sorry for the late response, I tried the launch command, no dice sadly. Still launches normally. I'm wondering if I should install Revive in the same prefix as DiRT Rally. I'm not so sure

BoofOof32 commented 1 year ago

it's been a hot minute since I came back here, but I'm throwing in the towel for now. I think for now, if we want to have any chance of this happening, the Wine bugs will need to be fixed for the Oculus Launcher. I will continue to maintain the appdb page for it on Winehq, but otherwise, I won't be much of use here :(

Oman395 commented 1 year ago

Jumping in 3 months later, and thanks to the archwiki I found oculus wine wrapper which seems promising, I'll report back in a bit once I get home and actually test it. I'm pretty sure it's based on the old 2017 version of the oculus SDK for linux, so I'm not quite sure how well it will work (especially for newer titles), but who knows? It might work great.

E: apparently im bad at links

twhitehead commented 1 year ago

I have been looking at getting Condor 2 working. It is a standalone application, so that should simplify some things. The issue I am currently facing is Condor 2 is 32 bit and Revive is 64 bit.

Ideally this shouldn't matter, but Revive uses Detours to inject itself into the application to hook the oculus calls. Detours generally seems to work under Linux. Here is, for example, an example of using it via ReviveInjector.exe to inject revive into the 64bit putty.exe

$ wine Program\ Files/Revive/ReviveInjector.exe putty64.exe
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:wineusb:query_id Unhandled ID query type 0x5.
0084:fixme:wineusb:query_id Unhandled ID query type 0x5.
0084:fixme:wineusb:query_id Unhandled ID query type 0x5.
0084:fixme:wineusb:query_id Unhandled ID query type 0x5.
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
Launched injector with: "C:\Program Files\Revive\ReviveInjector.exe" putty64.exe
Command for injector is: putty64.exe
Succesfully injected!
0118:fixme:ver:GetCurrentPackageId (000000000011FDA0 0000000000000000): stub

and the putty GUI comes up and works fine.

When you try and launch the 32 bit putty though, things go sideways

$ wine Program\ Files/Revive/ReviveInjector.exe putty32.exe
Launched injector with: "C:\Program Files\Revive\ReviveInjector.exe" putty32.exe
Command for injector is: putty32.exe
wine: Unhandled page fault on write access to 00400000 at address 1001047E (thread 014c), starting debugger...
0168:fixme:imm:ImeSetActiveContext (00030056, 1): stub
0168:fixme:imm:ImmReleaseContext (0003005A, 00030056): stub
0154:fixme:imm:ImeSetActiveContext (0000000000020030, 0): stub
0154:fixme:imm:ImmReleaseContext (00000000000200AA, 0000000000020030): stub

and a popup comes up saying

The program rundll32.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience.

Looking through the code, it seems rundll32.exe is used as a shim when there is a 32/64bit mismatch between the Detours application (ReviveInjector.exe) and the target application (Condor2.exe). So so much for 32/64. Given that 64/64 works though, it seems reasonable that 32/32 probably works as well. If I could just get my hands on a 32bit version of ReviveInjector.exe or Detours (which provides withdll.exe for also launching a programming and injecting a dll into it) I could test this.

And that is the problem. If it was all Linux, I would just build it myself. Neither of these projects seem setup for cross compilation, and I don't have Windows (the last time I seriously used it was NT 4). So I am posting here in case anyone has any ideas. ~If I don't hear anything, I will probably try and modify this project (which works by using detours under wine to do a dll injection) at some point as it comes with some cross compilation instructions and might be easily modify to inject the 32bit revive dll.~ (had a look and it #ifdefs out detours with gcc).

CrossVR commented 1 year ago

I wonder if you could use wine's built-in dll replacement mechanism. Ultimately the reason the injector is needed is so LibOVRRT32_1.dll is replaced with LibRevive32.dll.

So you could potentially rename LibRevive32.dll to LibOVRRT32_1.dll, then place it in the folder for wine's built-in DLLs and then configure wine to use the built-in DLL rather than the native one. Using this method you shouldn't ever need to run the injector, you can just run the game executable directly.

For that to work though there still needs to be a copy of the original LibOVRRT32_1.dll somewhere in the DLL search path. So make sure you either install the Oculus software under wine or grab a copy of the original DLL somewhere and place it next to the game executable.

twhitehead commented 1 year ago

Thanks. I will see if I can make that work. Out of curiosity, why is the original version still required somewhere on the DLL search path?

CrossVR commented 1 year ago

Every application, unless built with the latest SDK, does a signature check on the LibOVR DLL in its search path before attempting to load the DLL. If it can't find the DLL or the code signature chain doesn't match the Oculus one it will refuse to load.

twhitehead commented 1 year ago

Thanks. I tried a variety of things, but, even without trying to do any redirects, it looks to be failing at the verification stage. Putting just LibOVRRT32_1.dll in the windows/system32 folder and running with WINEDEBUG=+wintrust,+loaddll,+file,+reg gives

  1. it logs Oculus Rift initialization started (to the condor log file) and then looks for LibOVRRT32_1.dll 
    0024:trace:file:RtlDosPathNameToNtPathName_U_WithStatus (L"C:\\Condor2\\LibOVRRT32_1.dll",0021EA38,00000000,00000000)
0024:trace:file:RtlGetFullPathName_U (L"C:\\Condor2\\LibOVRRT32_1.dll" 520 0021E7E8 00000000)
0024:trace:file:nt_to_unix_file_name_no_root L"Condor2\\LibOVRRT32_1.dll" not found in /home/tyson/.wine-condor/dosdevices/c:/Condor2
0024:warn:file:NtQueryAttributesFile L"\\??\\C:\\Condor2\\LibOVRRT32_1.dll" not found (c0000034)
0024:trace:file:RtlDosPathNameToNtPathName_U_WithStatus (L".\\LibOVRRT32_1.dll",0021EA38,00000000,00000000)
0024:trace:file:RtlGetFullPathName_U (L".\\LibOVRRT32_1.dll" 520 0021E7E8 00000000)
0024:trace:file:nt_to_unix_file_name_no_root L"Condor2\\LibOVRRT32_1.dll" not found in /home/tyson/.wine-condor/dosdevices/c:/Condor2
0024:warn:file:NtQueryAttributesFile L"\\??\\C:\\Condor2\\LibOVRRT32_1.dll" not found (c0000034)
0024:trace:file:RtlDosPathNameToNtPathName_U_WithStatus (L"C:\\windows\\system32\\LibOVRRT32_1.dll",0021EA38,00000000,00000000)
0024:trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\LibOVRRT32_1.dll" 520 0021E7E8 00000000)
0024:trace:file:nt_to_unix_file_name_no_root L"\\??\\C:\\windows\\system32\\LibOVRRT32_1.dll" -> "/home/tyson/.wine-condor/dosdevices/c:/windows/system32/LibOVRRT32_1.dll"
0024:trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\LibOVRRT32_1.dll" 520 0021EC64 00000000)
0024:trace:file:SearchPathW found L"C:\\windows\\system32\\LibOVRRT32_1.dll"
0024:trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\LibOVRRT32_1.dll" 520 0021F074 00000000)
0024:trace:file:CreateFileW L"C:\\windows\\system32\\LibOVRRT32_1.dll" GENERIC_READ FILE_SHARE_READ  creation 3 attributes 0x1
0024:trace:file:RtlDosPathNameToNtPathName_U_WithStatus (L"C:\\windows\\system32\\LibOVRRT32_1.dll",0021EA40,00000000,00000000)
0024:trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\LibOVRRT32_1.dll" 520 0021E748 00000000)
0024:trace:file:NtCreateFile handle=0x21ea3c access=80100080 name=L"\\??\\C:\\windows\\system32\\LibOVRRT32_1.dll" objattr=00000040 root=(nil) sec=(nil) io=0x21ea48 alloc_size=(nil) attr=00000001 sharing=00000001 disp=1 options=00000060 ea=(nil).0x00000000
0024:trace:file:nt_to_unix_file_name_no_root L"\\??\\C:\\windows\\system32\\LibOVRRT32_1.dll" -> "/home/tyson/.wine-condor/dosdevices/c:/windows/system32/LibOVRRT32_1.dll"
0024:trace:file:CreateFileW returning 00000134
  2. it loads wintrust.dll and dependencies (omitted) and then calls WinVerifyTrust on LibOVRRT32_1.dll 
    ...
0024:trace:wintrust:WinVerifyTrust (FFFFFFFF, {00aac56b-cd44-11d0-8cc2-00c04fc295ee}, 0021E58C)
0024:trace:wintrust:dump_wintrust_data 0021E58C
0024:trace:wintrust:dump_wintrust_data cbStruct: 52
0024:trace:wintrust:dump_wintrust_data pPolicyCallbackData: 00000000
0024:trace:wintrust:dump_wintrust_data pSIPClientData: 00000000
0024:trace:wintrust:dump_wintrust_data dwUIChoice: 2
0024:trace:wintrust:dump_wintrust_data fdwRevocationChecks: 00000000
0024:trace:wintrust:dump_wintrust_data dwUnionChoice: 1
0024:trace:wintrust:dump_file_info 0021E5C0
0024:trace:wintrust:dump_file_info cbStruct: 16
0024:trace:wintrust:dump_file_info pcwszFilePath: L"C:\\windows\\system32\\LibOVRRT32_1.dll"
0024:trace:wintrust:dump_file_info hFile: 00000134
0024:trace:wintrust:dump_file_info pgKnownSubject: (null)
0024:trace:wintrust:dump_wintrust_data dwStateAction: 1
0024:trace:wintrust:dump_wintrust_data hWVTStateData: 00000000
0024:trace:wintrust:dump_wintrust_data pwszURLReference: (null)
0024:trace:wintrust:dump_wintrust_data dwProvFlags: 00000010
0024:trace:wintrust:dump_wintrust_data dwUIContext: 0
0024:trace:wintrust:WINTRUST_DefaultVerify (FFFFFFFF, {00aac56b-cd44-11d0-8cc2-00c04fc295ee}, 0021E58C)
  3. it makes many many crypto calls (omitted) before finally returning success (0) 
    ...
0024:trace:wintrust:WINTRUST_DefaultVerify returning 00000000
0024:trace:wintrust:WinVerifyTrust returning 00000000
  4. it looks into the details of the signatures (I think this is what goes south) 
    0024:trace:wintrust:WTHelperProvDataFromStateData 008D55D0
0024:trace:wintrust:WTHelperGetProvSignerFromChain (008D55D0 0 0 0)
0024:trace:wintrust:WTHelperGetProvSignerFromChain returning 008EBC60
  5. then it closes out the WinVerifyTrust operation 
    0024:trace:wintrust:WinVerifyTrust (FFFFFFFF, {00aac56b-cd44-11d0-8cc2-00c04fc295ee}, 0021E58C)
0024:trace:wintrust:dump_wintrust_data 0021E58C
0024:trace:wintrust:dump_wintrust_data cbStruct: 52
0024:trace:wintrust:dump_wintrust_data pPolicyCallbackData: 00000000
0024:trace:wintrust:dump_wintrust_data pSIPClientData: 00000000
0024:trace:wintrust:dump_wintrust_data dwUIChoice: 2
0024:trace:wintrust:dump_wintrust_data fdwRevocationChecks: 00000000
0024:trace:wintrust:dump_wintrust_data dwUnionChoice: 1
0024:trace:wintrust:dump_file_info 0021E5C0
0024:trace:wintrust:dump_file_info cbStruct: 16
0024:trace:wintrust:dump_file_info pcwszFilePath: L"C:\\windows\\system32\\LibOVRRT32_1.dll"
0024:trace:wintrust:dump_file_info hFile: 00000134
0024:trace:wintrust:dump_file_info pgKnownSubject: (null)
0024:trace:wintrust:dump_wintrust_data dwStateAction: 2
0024:trace:wintrust:dump_wintrust_data hWVTStateData: 008D55D0
0024:trace:wintrust:dump_wintrust_data pwszURLReference: (null)
0024:trace:wintrust:dump_wintrust_data dwProvFlags: 00000010
0024:trace:wintrust:dump_wintrust_data dwUIContext: 0
0024:trace:wintrust:WINTRUST_DefaultClose (FFFFFFFF, {00aac56b-cd44-11d0-8cc2-00c04fc295ee}, 0021E58C)
0024:trace:wintrust:WINTRUST_DefaultClose returning 00000000
0024:trace:wintrust:WinVerifyTrust returning 00000000
  6. it repeats all these steps again and then logs _ovr_Initialize failed with error: ovrInitialize never called.

Nowhere in the logs are any loaddll related logs for LibOVRRT32_1.dll. It seems it never actually tries to load the dll, which is why I am guessing it didn't like something coming out of the verification (step 4) even though the system reported that it succeeded (step 2 and 3).

twhitehead commented 1 year ago

A a note, Condor comes with a LibOVR.dll. This library exports a subset of the symbols that LibOVRRT32_1.dll does. I assume it is responsible for the loading of LibOVRRT32_1.dll and probably mostly just a passthrough, so I tried replacing it with LibRevive32.dll on the off chance that would work. This just generated an invalid address exception.

twhitehead commented 1 year ago

The issue with the verification is that CertGetNameStringW is called to retrieve the issuer on the elements of the certificate chain using the CERT_NAME_ATTR_TYPE with pvTypePara set to NULL. The behaviour of this is undocumented and Windows retrieves the common name while Wine retrieves the email (enable the +crypt debug stream to see this).

For the subject it sets pvTypePara to szOID_COMMON_NAME (which is the proper way to get the common name) and both Windows and Wine retrieve the common name as they should. Here is some of the output of a test program I wrote to dump the results of walking the certificate chain and making these two call on Wine

chain                          0
  element                        0
    subject (CN)                   Oculus VR, LLC
    issuer (0)                     
  element                        1
    subject (CN)                   DigiCert SHA2 Assured ID Code Signing CA
    issuer (0)                     
  element                        2
    subject (CN)                   DigiCert Assured ID Root CA
    issuer (0)

and what you get on Windows

chain                          0
  element                        0
    subject (CN)                   Oculus VR, LLC
    issuer (0)                     DigiCert SHA2 Assured ID Code Signing CA
  element                        1
    subject (CN)                   DigiCert SHA2 Assured ID Code Signing CA
    issuer (0)                     DigiCert Assured ID Root CA
  element                        2
    subject (CN)                   DigiCert Assured ID Root CA
    issuer (0)                     DigiCert Assured ID Root CA

For the record, here is the complete chain

Issuer
  CERT_SIMPLE_NAME_STR           US, DigiCert Inc, www.digicert.com, DigiCert SHA2 Assured ID Code Signing CA
  CERT_OID_NAME_STR              2.5.4.6=US, 2.5.4.10=DigiCert Inc, 2.5.4.11=www.digicert.com, 2.5.4.3=DigiCert SHA2 Assured ID Code Signing CA
  CERT_X500_NAME_STR             C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 Assured ID Code Signing CA
Subject
  CERT_SIMPLE_NAME_STR           US, California, Menlo Park, "Oculus VR, LLC", "Facebook Technologies, LLC", "Oculus VR, LLC"
  CERT_OID_NAME_STR              2.5.4.6=US, 2.5.4.8=California, 2.5.4.7=Menlo Park, 2.5.4.10="Oculus VR, LLC", 2.5.4.11="Facebook Technologies, LLC", 2.5.4.3="Oculus VR, LLC"
  CERT_X500_NAME_STR             C=US, S=California, L=Menlo Park, O="Oculus VR, LLC", OU="Facebook Technologies, LLC", CN="Oculus VR, LLC"
Issuer
  CERT_SIMPLE_NAME_STR           US, DigiCert Inc, www.digicert.com, DigiCert Assured ID Root CA
  CERT_OID_NAME_STR              2.5.4.6=US, 2.5.4.10=DigiCert Inc, 2.5.4.11=www.digicert.com, 2.5.4.3=DigiCert Assured ID Root CA
  CERT_X500_NAME_STR             C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root CA
Subject
  CERT_SIMPLE_NAME_STR           US, DigiCert Inc, www.digicert.com, DigiCert SHA2 Assured ID Code Signing CA
  CERT_OID_NAME_STR              2.5.4.6=US, 2.5.4.10=DigiCert Inc, 2.5.4.11=www.digicert.com, 2.5.4.3=DigiCert SHA2 Assured ID Code Signing CA
  CERT_X500_NAME_STR             C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 Assured ID Code Signing CA
Issuer
  CERT_SIMPLE_NAME_STR           US, DigiCert Inc, www.digicert.com, DigiCert Assured ID Root CA
  CERT_OID_NAME_STR              2.5.4.6=US, 2.5.4.10=DigiCert Inc, 2.5.4.11=www.digicert.com, 2.5.4.3=DigiCert Assured ID Root CA
  CERT_X500_NAME_STR             C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root CA
Subject
  CERT_SIMPLE_NAME_STR           US, DigiCert Inc, www.digicert.com, DigiCert Assured ID Root CA
  CERT_OID_NAME_STR              2.5.4.6=US, 2.5.4.10=DigiCert Inc, 2.5.4.11=www.digicert.com, 2.5.4.3=DigiCert Assured ID Root CA
  CERT_X500_NAME_STR             C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root CA

You can see these are no email fields, which is why Wine is failing to retrieve anything. Not that it would likely be accepted anyway if the common name is expected.

CrossVR commented 1 year ago

Nice find, sounds like something that would need to be fixed in Wine?

twhitehead commented 1 year ago

That is correct. Wasn't a big deal though, so I threw together a patch for it and submitted it upstream.

Did some more testing on Windows and turns out that it wasn't that it retrieved the email and not the common name, but that Windows tried email, common name, organization name, and then organization, while Wine just gave up after email, which this chain doesn't have.

In any event, tested it and pleased to report that with this fixed it then goes on to load LibOVRRT32_1.dll. I couldn't see how to use the Wine DLL overloading to choose one native DLL over another (it only seems to have the option of choosing between builtin and native), but I did find a 32 DLL injector.

So I gave that a go with a patched wine

$ WINEDEBUG=+wintrust,+loaddll,+file,+crypt wine 'C:\Condor2\dll_injector32.exe' /dll 'C:\Condor2\LibRevive32.dll' /target 'C:\Condor2\Condor.exe'
...
[*] Debug privilege set!
DLL: C:\Condor2\LibRevive32.dll
PID: 292
Selected Action: LOAD
Injection OK!
...

and it works. Well, it works up to the point were Revive starts to initialize OpenVR and it tries to open C:\users\tyson\AppData\Local\openvr\openvrpaths.vrpath. I don't actually have OpenVR installed under the wine I built, so it then fails and Condor logs the message

ovr_Initialize failed with error: Installation path could not be located (110).

So what I need now is a patched wine with OpenVR (or OpenXR) support. I think the only wine with OpenVR or OpenXR is Steam's Proton though, and I don't have any experience building it. The best hope might be to see if I can get this patch included in a Proton Glourious Eggroll release as that would be faster than waiting for Wine to merge it and then Valve to rebase Proton on top of a Wine with the patch.

The other approach I that might work would be to take the Proton OpenXR DLL code and put it in standard Wine it see if it would build Wine with a OpenXR DLL for Revive to use.

CrossVR commented 1 year ago

Could also try a pull request against Valve's wine fork: https://github.com/ValveSoftware/wine/pulls

twhitehead commented 1 year ago

The only request from wine was for a test case. I have now done this, so seems hopeful it will be merged.

Annoyingly I just missed 8.4, which they released last night.

Excellent suggestion to do a pull request against Valve's wine fork too BTW. I have now done this as well.

BoofOof32 commented 1 year ago

I haven't checked in a few months, but all of this recent activity was a pleasant surprise. I still won't be all that useful, but I Just wanna say I appreciate the work done so far. I'm still open to testing anything if need be (once I get ALVR to work again, lol)

twhitehead commented 1 year ago

I don't think there is much else we can do until we have a version of wine with OpenVR (or OpenXR?) support and the patch that makes the verification succeed. Upstream has merged the patch now, so that is good. Unless Valve chooses to apply it too though, they aren't going to get it until they catch up with 8.5, which might be awhile considering they are still on 7.0.

I did spend some time looking at the Valve's wineopenxr.

You cannot build it against the 8.x branch of wine without some non-minor modifications as the Windows/UNIX world split has changed quite a bit (the newer unix call system). It isn't impossible though, and there are lots of good examples of how it is done with other Khronos interfaces, including opengl and vulkan. Most of it is auto generated from the Khronos XML API files by a python make_<api> script.

Another thing that could be tried would be to path wine 7.0 and then try building Valve's wineopenxr against that.

twhitehead commented 1 year ago

Actually, it occurs to me now that all you need is a new crypt32.dll built against the Valve environment. They you could copy that over top of the proton one and be on your way.

So all that is really required is to have a VM with whatever distro and version Valve is basing their stack on (I seem to recall it was some version of Debian or Ubuntu?) and then build a patched wine 7.0 in it. Copy the crypt32.dll over from that to the proton directory and you should then be good to go (or, at least, discover what the next issue is).

Crashdummyy commented 1 year ago

Is there any progress on this ? Given that the fallback of the crypt32.dll is merged already and GE-Proton uses the latest bleeding edge version of wine it should be possible to use revive right now, shouldnt it ?

So how would I go about testing it ? Do I need to compile it for linux first if thats even possible ?

Or is it as easy as -> Start ALVR -> Start Revive through proton-ge -> Start Oculus game through proton-ge

?

BoofOof32 commented 1 year ago

I've been meaning to come back to this issue, but didn't really know if I'd have anything meaningful to add. Knowing GE-Proton likely has the patch, I'll feel more inclined to give this another test

twhitehead commented 1 year ago

I looked into the GE build earlier, and I could be totally out to lunch, but my recollect is that they weren't build the VR stuff. Does anyone know differently?

If my recollect is correct, and they are building with the patch though, possibly their crpyt32.dll could still be lifted for use with Steam's proton?

BoofOof32 commented 1 year ago

yeah, I'm remembering why I had a hard time getting far last time. I think the killer for me is ALVR has not been super performant, it's a blocky mess on my end (maybe internet issues). So it's hard to test much. I don't think I'm competent enough to really tinker and get Oculus games functioning, there's a lot of prefix wizardry to figure out

JD-The-65th commented 1 year ago

Hey, any update on this? I tried using GE-Proton8-10 with Revive and Among Us VR but it crashed on open. I don't have the oculus runtime installed since it'd take up ssd space, and I really don't wanna buy Among Us VR on Steam just to play it using ALVR so having Revive working would be a godsend.

Crashdummyy commented 1 year ago

Hey, any update on this? I tried using GE-Proton8-10 with Revive and Among Us VR but it crashed on open. I don't have the oculus runtime installed since it'd take up ssd space, and I really don't wanna buy Among Us VR on Steam just to play it using ALVR so having Revive working would be a godsend.

Same for Asgard's wrath with either 8-8 or 8-10 :/

twhitehead commented 1 year ago

Pretty sure the patch isn't in the wine the official proton or GE releases are being built against yet as it just missed making it into the upstream 8 release by a day or two. My pull request to get it into their wine hasn't went anywhere yet.

Etaash-mathamsetty commented 11 months ago

This is an unfortunate situation, so I'll ask GE to add this patch as backport for the next GE release, whenever that is.

Or y'all can just wait for proton 9.0 next year :) but I don't think any of you want that

Bitwolfies commented 10 months ago

Made it in: https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton8-21

Etaash-mathamsetty commented 10 months ago

Made it in: https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton8-21

Yep, could one of you test with 8-21 ?

twhitehead commented 10 months ago

That is great news! Thanks! I will give it a test when I get back (on vacation at the moment).

Do you know if proton-ge has the rest of the steam VR stack (i.e., the Valve OpenVR for their Index)?

Crashdummyy commented 10 months ago

So kewl :) I'll test it once I'm back from vacation

Etaash-mathamsetty commented 10 months ago

That is great news! Thanks! I will give it a test when I get back (on vacation at the moment).

Do you know if proton-ge has the rest of the steam VR stack (i.e., the Valve OpenVR for their Index)?

yes it should

twhitehead commented 10 months ago

I have tested it now. I am no longer running into any issues with the LibOVR* libraries loading. So the patch is working great!

Unfortunately Condor2 is still having some issues. I tested the latest Revive (3.2.0) and several prior version (3.1.1, 2.1.1, 1.9.2). I also searched quite a bit for a very basic (e.g., just displays some text, an image, a skybox, that sort of thing) standalone Windows Oculus program to test. I couldn't find anything. If anyone knows of one, please post a link.

How To

  1. native install of Install GE proton 8-22 release
  2. add Condor 2 installer as a non-steam game and run in
  3. change target property to be cmd.exe in windows/system32 folder and run it
  4. locate ~/.local/share/Steam/steamapps/compatdata/*/pfx/drive_c/ folder
  5. copy ReviveInstaller.exe in and run it
  6. copy LibRevive32.dll and openvr_api32.dll from Revive to Condor 2
  7. download `dll_injector32.exe' and copy to Condor 2
  8. download LibOVRRT32_1.dll (google drive link at end of post) and copy to Condor 2
  9. start Condor from cmd.exe with dll_injector32.exe /dll librevive32.dll /target condor.exe

To enable wine logs, see ~/.local/share/Steam/compatibilitytools.d/GE-Proton8-22/user_settings.sample.py. I set

"PROTON_LOG": "1"
"WINEDEBUG": "+timestamp,+pid,+tid,+seh,+unwind,+threadname,+debugstr,+loaddll,+mscoree,+file,+relay,+snoop"

The log file is ~/steam-*.log

Latest Revive (3.2.0)

Upon starting a flight,

Running under wine with a lot of tracing enabled generates a very large (100s of MBs) log file. Here is a summary of just the cross-library calls between LibRevive32, openvr_api32, and vrclient, plus environment queries and DLL loads

3250011.053:0148:014c:CALL LibRevive32.ovr_Initialize(<unknown, check return>) ret=013030be
3250011.053:0148:014c:CALL openvr_api32.VR_InitInternal2(00a0f47c,00000001,00000000) ret=0244fe17
3250011.053:0148:014c:Call KERNEL32.GetEnvironmentVariableA(025896f4 "VR_PATHREG_OVERRIDE",00a07078,00007fff) ret=025329c9
3250011.053:0148:014c:Ret  KERNEL32.GetEnvironmentVariableA() retval=00000000 ret=025329c9
3250011.061:0148:014c:Call KERNEL32.GetEnvironmentVariableA(02586054 "VR_OVERRIDE",00a072e0,00007fff) ret=025329c9
3250011.061:0148:014c:Ret  KERNEL32.GetEnvironmentVariableA() retval=00000000 ret=025329c9
3250011.061:0148:014c:Call KERNEL32.GetEnvironmentVariableA(02586060 "VR_CONFIG_PATH",00a072e0,00007fff) ret=025329c9
3250011.061:0148:014c:Ret  KERNEL32.GetEnvironmentVariableA() retval=00000000 ret=025329c9
3250011.061:0148:014c:Call KERNEL32.GetEnvironmentVariableA(02586070 "VR_LOG_PATH",00a072e0,00007fff) ret=025329c9
3250011.061:0148:014c:Ret  KERNEL32.GetEnvironmentVariableA() retval=00000000 ret=025329c9
3250011.069:0148:014c:trace:loaddll:build_module Loaded L"C:\\vrclient\\bin\\vrclient.dll" at D0780000: builtin
3250011.070:0148:014c:Call vrclient.VRClientCoreFactory(02586040,00a0f43c) ret=025322d9
3250011.070:0148:014c:Call KERNEL32.GetEnvironmentVariableW(d093c800 L"PROTON_VR_RUNTIME",00a0d320,00001000) ret=d0794a22
3250011.070:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000037 ret=d0794a22
3250011.086:0148:014c:Ret  vrclient.VRClientCoreFactory() retval=02a01c60 ret=025322d9
3250016.276:0148:014c:RET  openvr_api32.VR_InitInternal2() retval=00000001 ret=0244fe17
3250016.276:0148:014c:CALL openvr_api32.VR_IsInterfaceVersionValid(02491278) ret=0244fe47
3250016.292:0148:014c:RET  openvr_api32.VR_IsInterfaceVersionValid() retval=00000001 ret=0244fe47
3250016.292:0148:014c:CALL openvr_api32.VR_GetInitToken(<unknown, check return>) ret=0244fe50
3250016.292:0148:014c:RET  openvr_api32.VR_GetInitToken() retval=00000001 ret=0244fe50
3250016.292:0148:014c:CALL openvr_api32.VR_GetGenericInterface(02491278,00a0f478) ret=0244fe7d
3250016.292:0148:014c:RET  openvr_api32.VR_GetGenericInterface() retval=02a01ca0 ret=0244fe7d

and then the SEH handler gets invoked (there are additional Windows API calls, but no more between the libraries, and the initial LibRevive32.ovr_Initialize call never returns

3250016.292:0148:014c:trace:seh:dispatch_exception code=c0000005 flags=0 addr=0244FEEC ip=0244feec
3250016.292:0148:014c:trace:seh:dispatch_exception  info[0]=00000000
3250016.292:0148:014c:trace:seh:dispatch_exception  info[1]=746e6579
3250016.292:0148:014c:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised
3250016.292:0148:014c:trace:seh:dispatch_exception  eax=00000000 ebx=025a0022 ecx=2e49644d edx=00000040 esi=746e6569 edi=025a0033
3250016.292:0148:014c:trace:seh:dispatch_exception  ebp=00a0f484 esp=00a0f46c cs=0023 ss=002b ds=002b es=002b fs=0063 gs=006b flags=00010216

Older Revives (3.1.1, 2.1.1, 1.9.2)

Upon starting a flight,

Here is a summary of just the cross-library calls between LibRevive32, openvr_api32, and vrclient, plus environment queries and DLL loads for an earlier version (I didn't trace them all as they all seems to be similar)

3186083.677:0148:014c:CALL LibRevive32.ovr_Initialize(<unknown, check return>) ret=010230be
3186083.677:0148:014c:CALL openvr_api32.VR_InitInternal2(009ff47c,00000001,00000000) ret=02440a95
3186083.677:0148:014c:Call KERNEL32.GetEnvironmentVariableA(025940d8 "VR_PATHREG_OVERRIDE",009f7140,00007fff) ret=02540ac9
3186083.677:0148:014c:Ret  KERNEL32.GetEnvironmentVariableA() retval=00000000 ret=02540ac9
3186083.682:0148:014c:Call KERNEL32.GetEnvironmentVariableA(025912f0 "VR_OVERRIDE",009f72f4,00007fff) ret=02540ac9
3186083.682:0148:014c:Ret  KERNEL32.GetEnvironmentVariableA() retval=00000000 ret=02540ac9
3186083.682:0148:014c:Call KERNEL32.GetEnvironmentVariableA(025912fc "VR_CONFIG_PATH",009f72f4,00007fff) ret=02540ac9
3186083.682:0148:014c:Ret  KERNEL32.GetEnvironmentVariableA() retval=00000000 ret=02540ac9
3186083.682:0148:014c:Call KERNEL32.GetEnvironmentVariableA(0259130c "VR_LOG_PATH",009f72f4,00007fff) ret=02540ac9
3186083.682:0148:014c:Ret  KERNEL32.GetEnvironmentVariableA() retval=00000000 ret=02540ac9
3186083.692:0148:014c:trace:loaddll:build_module Loaded L"C:\\vrclient\\bin\\vrclient.dll" at D1180000: builtin
3186083.692:0148:014c:Call vrclient.VRClientCoreFactory(025912dc,009ff428) ret=0254029d
3186083.692:0148:014c:Call KERNEL32.GetEnvironmentVariableW(d133c800 L"PROTON_VR_RUNTIME",009fd300,00001000) ret=d1194a22
3186083.692:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000037 ret=d1194a22
3186083.708:0148:014c:Ret  vrclient.VRClientCoreFactory() retval=02a113f0 ret=0254029d
3186086.432:0148:014c:RET  openvr_api32.VR_InitInternal2() retval=00000001 ret=02440a95
3186086.432:0148:014c:CALL openvr_api32.VR_IsInterfaceVersionValid(02497234) ret=02440ac5
3186086.432:0148:014c:RET  openvr_api32.VR_IsInterfaceVersionValid() retval=00000001 ret=02440ac5
3186086.432:0148:014c:CALL openvr_api32.VR_GetInitToken(<unknown, check return>) ret=02440ace
3186086.432:0148:014c:RET  openvr_api32.VR_GetInitToken() retval=00000001 ret=02440ace
3186086.432:0148:014c:CALL openvr_api32.VR_GetGenericInterface(02497234,009ff478) ret=02440afb
3186086.432:0148:014c:RET  openvr_api32.VR_GetGenericInterface() retval=02a11330 ret=02440afb
3186086.432:0148:014c:CALL openvr_api32.VR_GetInitToken() ret=02440b33
3186086.432:0148:014c:RET  openvr_api32.VR_GetInitToken() retval=00000001 ret=02440b33
3186086.432:0148:014c:CALL openvr_api32.VR_GetGenericInterface(02497258,009ff478) ret=02440b64
3186086.432:0148:014c:RET  openvr_api32.VR_GetGenericInterface() retval=02a11370 ret=02440b64
3186086.432:0148:014c:CALL openvr_api32.VR_GetInitToken() ret=02440b84
3186086.432:0148:014c:RET  openvr_api32.VR_GetInitToken() retval=00000001 ret=02440b84
3186086.432:0148:014c:RET  LibRevive32.ovr_Initialize() retval=00000000 ret=010230be
3186086.446:0148:014c:CALL LibRevive32.ovr_Create(<unknown, check return>) ret=02190000
3186086.447:0148:014c:CALL openvr_api32.VR_GetInitToken() ret=0243d2e9
3186086.447:0148:014c:RET  openvr_api32.VR_GetInitToken() retval=00000001 ret=0243d2e9
3186086.447:0148:014c:CALL openvr_api32.VR_GetGenericInterface(0249727c,009ff1f4) ret=0243d317
3186086.447:0148:014c:RET  openvr_api32.VR_GetGenericInterface() retval=02a11430 ret=0243d317
3186086.447:0148:014c:CALL openvr_api32.VR_GetInitToken() ret=0243d3af
3186086.447:0148:014c:RET  openvr_api32.VR_GetInitToken() retval=00000001 ret=0243d3af
3186086.447:0148:014c:CALL openvr_api32.VR_GetGenericInterface(0249726c,009ff1cc) ret=0243d3dc
3186086.447:0148:014c:RET  openvr_api32.VR_GetGenericInterface() retval=02a11470 ret=0243d3dc
... many VR_GetInitToken() calls ...
3186112.100:0148:014c:CALL openvr_api32.VR_IsHmdPresent(<unknown, check return>) ret=0244525d
3186112.100:0148:014c:RET  openvr_api32.VR_IsHmdPresent() retval=00000001 ret=0244525d
... a few VR_GetInitToken() calls ...
3186112.105:0148:014c:Call KERNEL32.GetEnvironmentVariableW(070f8840 L"DXVK_ENABLE_NVAPI",0213b340,00000104) ret=6f496200
3186112.105:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=6f496200
3186112.105:0148:014c:Call KERNEL32.GetEnvironmentVariableW(070f8840 L"DXVK_HDR",0213b340,00000104) ret=6f496200
3186112.105:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=6f496200
3186112.105:0148:014c:Call KERNEL32.GetEnvironmentVariableW(06fbd100 L"DXVK_MONITOR_FALLBACK",0213b340,00000104) ret=6f496200
3186112.105:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=6f496200
... many VR_GetInitToken() calls ...
3186112.512:0148:014c:RET  LibRevive32.ovr_Create() retval=00000000 ret=02190000
3186112.513:0148:014c:CALL LibRevive32.ovr_GetHmdDesc(<unknown, check return>) ret=010228f7
3186112.513:0148:014c:RET  LibRevive32.ovr_GetHmdDesc() retval=009ff3b8 ret=010228f7
3186112.513:0148:014c:CALL LibRevive32.ovr_GetFovTextureSize(<unknown, check return>) ret=01022883
3186112.513:0148:014c:RET  LibRevive32.ovr_GetFovTextureSize() retval=000007e0 ret=01022883
3186112.513:0148:014c:CALL LibRevive32.ovr_GetFovTextureSize() ret=01022883
3186112.513:0148:014c:RET  LibRevive32.ovr_GetFovTextureSize() retval=000007e0 ret=01022883
3186112.513:0148:014c:CALL LibRevive32.ovr_SetTrackingOriginType(<unknown, check return>) ret=02190000
3186112.513:0148:014c:RET  LibRevive32.ovr_SetTrackingOriginType() retval=00000000 ret=02190000
3186112.513:0148:014c:Call KERNEL32.GetEnvironmentVariableW(070f8840 L"DXVK_ENABLE_NVAPI",0213b340,00000104) ret=6f496200
3186112.513:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=6f496200
3186112.513:0148:0620:CALL openvr_api32.VR_GetInitToken() ret=0243e490
3186112.513:0148:0620:RET  openvr_api32.VR_GetInitToken() retval=00000001 ret=0243e490
3186112.513:0148:014c:Call KERNEL32.GetEnvironmentVariableW(070f8840 L"DXVK_HDR",0213b340,00000104) ret=6f496200
3186112.513:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=6f496200
3186112.513:0148:014c:Call KERNEL32.GetEnvironmentVariableW(06fbd100 L"DXVK_MONITOR_FALLBACK",0213b340,00000104) ret=6f496200
3186112.513:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=6f496200
... many VR_GetInitToken() calls ...
3186114.384:0148:014c:Call KERNEL32.GetEnvironmentVariableW(070f8de0 L"DXVK_STATE_CACHE",0213b340,00000104) ret=6a694000
3186114.384:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=6a694000
3186114.384:0148:014c:Call KERNEL32.GetEnvironmentVariableW(02082a28 L"DXVK_STATE_CACHE_PATH",0213b340,00000104) ret=6a694000
3186114.384:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000050 ret=6a694000
... several VR_GetInitToken() calls ...
3186114.419:0148:014c:Call KERNEL32.GetEnvironmentVariableW(020829a8 L"DXVK_SHADER_DUMP_PATH",0213c880,00000104) ret=6a694000
3186114.419:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=6a694000
3186114.419:0148:0620:CALL openvr_api32.VR_GetInitToken() ret=0243e490
3186114.419:0148:0620:RET  openvr_api32.VR_GetInitToken() retval=00000001 ret=0243e490
3186114.424:0148:014c:Call KERNEL32.GetEnvironmentVariableW(02116050 L"DXVK_FRAME_RATE",0213c880,00000104) ret=6a694000
3186114.424:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=6a694000
3186114.425:0148:061c:CALL openvr_api32.VR_GetInitToken() ret=0243e490
3186114.425:0148:061c:RET  openvr_api32.VR_GetInitToken() retval=00000001 ret=0243e490
3186114.425:0148:0620:CALL openvr_api32.VR_GetInitToken() ret=0243e490
3186114.425:0148:0620:RET  openvr_api32.VR_GetInitToken() retval=00000001 ret=0243e490
3186114.425:0148:014c:Call KERNEL32.GetEnvironmentVariableW(021161d0 L"DXVK_HUD",0213cee0,00000104) ret=6a694000
3186114.425:0148:014c:Ret  KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=6a694000
... several VR_GetInitToken() calls ...
3186114.444:0148:014c:CALL LibRevive32.ovr_CreateTextureSwapChainDX(<unknown, check return>) ret=02190000
... several VR_GetInitToken() calls ...
3186114.445:0148:014c:RET  LibRevive32.ovr_CreateTextureSwapChainDX() retval=00000000 ret=02190000
... several VR_GetInitToken() calls ...
3186114.464:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainLength(<unknown, check return>) ret=02190000
3186114.464:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainLength() retval=00000000 ret=02190000
3186114.464:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainBufferDX(02aac928,02a666d0,00000000,6f15aaf2,4e89d208,9548b49a,9c4fd335,009ff714) ret=01022bce
3186114.464:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainBufferDX() retval=00000000 ret=01022bce
3186114.464:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainBufferDX(02aac928,02a666d0,00000001,6f15aaf2,4e89d208,9548b49a,9c4fd335,009ff714) ret=01022bce
3186114.464:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainBufferDX() retval=00000000 ret=01022bce
3186114.464:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainBufferDX(02aac928,02a666d0,00000002,6f15aaf2,4e89d208,9548b49a,9c4fd335,009ff714) ret=01022bce
3186114.464:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainBufferDX() retval=00000000 ret=01022bce
... a few VR_GetInitToken() calls ...
3186114.470:0148:014c:CALL LibRevive32.ovr_CreateTextureSwapChainDX() ret=02190000
3186114.470:0148:014c:RET  LibRevive32.ovr_CreateTextureSwapChainDX() retval=00000000 ret=02190000
... a few VR_GetInitToken() calls ...
3186114.471:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainLength() ret=02190000
3186114.471:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainLength() retval=00000000 ret=02190000
3186114.471:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainBufferDX(02aac928,02a66730,00000000,6f15aaf2,4e89d208,9548b49a,9c4fd335,009ff714) ret=01022bce
3186114.471:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainBufferDX() retval=00000000 ret=01022bce
3186114.471:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainBufferDX(02aac928,02a66730,00000001,6f15aaf2,4e89d208,9548b49a,9c4fd335,009ff714) ret=01022bce
3186114.471:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainBufferDX() retval=00000000 ret=01022bce
3186114.471:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainBufferDX(02aac928,02a66730,00000002,6f15aaf2,4e89d208,9548b49a,9c4fd335,009ff714) ret=01022bce
3186114.471:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainBufferDX() retval=00000000 ret=01022bce
3186114.474:0148:014c:CALL LibRevive32.ovr_CreateTextureSwapChainDX() ret=02190000
3186114.474:0148:014c:RET  LibRevive32.ovr_CreateTextureSwapChainDX() retval=00000000 ret=02190000
3186114.474:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainLength() ret=02190000
3186114.474:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainLength() retval=00000000 ret=02190000
3186114.474:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainBufferDX(02aac928,02a66790,00000000,6f15aaf2,4e89d208,9548b49a,9c4fd335,009ff714) ret=01022bce
3186114.474:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainBufferDX() retval=00000000 ret=01022bce
3186114.474:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainBufferDX(02aac928,02a66790,00000001,6f15aaf2,4e89d208,9548b49a,9c4fd335,009ff714) ret=01022bce
3186114.474:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainBufferDX() retval=00000000 ret=01022bce
3186114.474:0148:014c:CALL LibRevive32.ovr_GetTextureSwapChainBufferDX(02aac928,02a66790,00000002,6f15aaf2,4e89d208,9548b49a,9c4fd335,009ff714) ret=01022bce
3186114.474:0148:014c:RET  LibRevive32.ovr_GetTextureSwapChainBufferDX() retval=00000000 ret=01022bce
... a few VR_GetInitToken calls ...
3186114.475:0148:014c:CALL LibRevive32.ovr_CreateMirrorTextureWithOptionsDX(<unknown, check return>) ret=02190000
3186114.475:0148:014c:RET  LibRevive32.ovr_CreateMirrorTextureWithOptionsDX() retval=00000000 ret=02190000
... many VR_GetInitToken calls ...
3186114.575:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: eax=00000037 ebx=009fd3ec ecx=0047e3e8 edx=009ff9e4 esi=009fd278 edi=009fd228
3186114.575:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: ebp=009fd23c esp=009fd1fc eip=7bc0baec cs=0023 ss=002b flags=00000246
3186114.575:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: ds=002b es=002b fs=0063 gs=006b
3186114.577:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: eax=00000037 ebx=009fd3ec ecx=0047e3e8 edx=009ff9e4 esi=009fd278 edi=009fd228
3186114.577:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: ebp=009fd23c esp=009fd1fc eip=7bc0baec cs=0023 ss=002b flags=00000246
3186114.577:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: ds=002b es=002b fs=0063 gs=006b
... a few VR_GetInitToken calls ...
3186114.578:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: eax=00000037 ebx=009fd3fc ecx=0047e3e8 edx=009ff9e4 esi=009fd288 edi=009fd238
3186114.578:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: ebp=009fd24c esp=009fd20c eip=7bc0baec cs=0023 ss=002b flags=00000246
3186114.578:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: ds=002b es=002b fs=0063 gs=006b
3186114.581:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: eax=00000037 ebx=009fd3ec ecx=0047e3e8 edx=009ff9e4 esi=009fd278 edi=009fd228
3186114.581:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: ebp=009fd23c esp=009fd1fc eip=7bc0baec cs=0023 ss=002b flags=00000246
3186114.581:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: ds=002b es=002b fs=0063 gs=006b
... a few VR_GetInitToken calls ...
3186114.582:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: eax=00000037 ebx=009fd3ec ecx=0047e3e8 edx=009ff9e4 esi=009fd278 edi=009fd228
3186114.582:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: ebp=009fd23c esp=009fd1fc eip=7bc0baec cs=0023 ss=002b flags=00000246
3186114.582:0148:014c:trace:seh:NtGetContextThread 0xfffffffe: ds=002b es=002b fs=0063 gs=006b
... many VR_GetInitToken calls ...
Etaash-mathamsetty commented 10 months ago

What address was LibRevive32 loaded at, the line containing this information should look something like

3250011.069:0148:014c:trace:loaddll:build_module Loaded L"C:\\vrclient\\bin\\vrclient.dll" at D0780000: builtin

but with a different dll obviously, to avoid any confusion, just send the whole line

twhitehead commented 10 months ago

In the log from the latest version (the early crash)

3249966.225:0148:0154:trace:loaddll:build_module Loaded L"C:\\Condor2\\LibRevive32.dll" at 02440000: native

In the log from the older versions (the later crash)

3186043.381:0148:0158:trace:loaddll:build_module Loaded L"C:\\Program Files (x86)\\Steam\\steamapps\\Condor2\\LibRevive32.dll" at 02430000: native

I also discovered that the older versions don't always make it way further. I expect there is some sort of uninitialized memory at play (consistently goes further or not when ran several time in a row, but then changes when I go and do other things with machine and them come back and try again).

Finally, found it a screenshot somewhere, there are wine debug channels steam and vr_client that provide additional VR related logging. I will rerun with these on when I get a change in hopes that their output will help. In the process of uploading the full logs too. Will take awhile though.

Etaash-mathamsetty commented 10 months ago

ok so the crash is probably happening in LibRevive32.dll, thanks