Linux #1571
Comments
|
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. |
|
Oh. I see... Tried both the legacy runtime and the newer one. Didn't even install... |
|
Then I'm afraid, until Oculus decides to support Linux as a platform, there's nothing to be done... |
|
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... 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 🙂 |
|
(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. |
|
Has anyone tried running revive under proton, and successfully downloaded and launched a game from the oculus store using that? |
|
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 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. 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 |
|
alright, so unfortunately, taking my Oculus Launcher install and putting it into the same prefix as Revive didn't really change anything 🙁. 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. |
|
@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? |
|
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 |
|
also, i just realized that latest commit didn't build successfully in Appveyor, strange |
|
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. |
|
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. |
|
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. |
|
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 :/ |
|
My bad, forgot to mention you need to add this to the launch options for Dirt Rally in Steam:
|
|
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 |
|
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 :( |
|
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 |
|
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 and the putty GUI comes up and works fine. When you try and launch the 32 bit putty though, things go sideways and a popup comes up saying Looking through the code, it seems 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. |
|
I wonder if you could use wine's built-in dll replacement mechanism. Ultimately the reason the injector is needed is so So you could potentially rename For that to work though there still needs to be a copy of the original |
|
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? |
|
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. |
|
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
Nowhere in the logs are any |
|
A a note, Condor comes with a |
|
The issue with the verification is that CertGetNameStringW is called to retrieve the issuer on the elements of the certificate chain using the For the subject it sets and what you get on Windows For the record, here is the complete chain 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. |
|
Nice find, sounds like something that would need to be fixed in Wine? |
|
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 So I gave that a go with a patched wine and it works. Well, it works up to the point were Revive starts to initialize OpenVR and it tries to open 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. |
|
Could also try a pull request against Valve's wine fork: https://github.com/ValveSoftware/wine/pulls |
|
Just a note that all the proton corrections (the crypto and the submit pose) are now in proton bleeding edge. This means they should be in the next proton bleeding edge beta and then eventually the next major proton stable. I would expect there is a good change they will be in the next Proton GE release as well. |
GE pulls directly from the BE tree so there's a great chance it will be in the next proton-ge. Thanks for your contributions :) |
|
Did someone manage to get AsgardsWrath running ?
I just copied the Directory from my old windows PC where I installed it using the oculus store those days. |
|
So I've discovered a while back that most Rift exclusives are a lost cause on Linux without a way of getting the Oculus launcher working, as there's no way of satisfying the entitlement checks (DRM) without it. EchoVR is an interesting case though. So following twhitehead's guide. If you attempt to try this with EchoVR, it will usually give you the failed OVR runtime error. But when launching the game, there is about a 15% chance it will fullscreen, and error out for a different reason Looking at one of the crashlogs, it may have something to do with the pnsovr dll |
That log is practically useless, do you have a proton log ? |
|
I went ahead and reran with |
|
Unfortunate, I don't think I can debug this without having the exe itself |
|
EchoVR was originally obtainable for free via the Oculus launcher. Nowadays you'll have to get it via a community installer since the game is dead in an official capacity |
|
so how would I go about debugging EchoVR if I may ask? |
|
decided to lower the target for now, and try the built-in demos on the Oculus launcher. I'm happy to report that I managed to get the Oculus Touch tutorial and First Contact to run https://youtu.be/CoMWTjUb8FA?si=l9HVPKuczXwlKgLn What's curious though is that a lot of the inputs don't register, like button presses and or finger detection from capacitive sensors, so I can only make this gesture |
|
@BoofOof32 nice going! Glad to see you successfully running some things! 🎉 |
|
I have a hunch that my troubles with EchoVR are due to VKD3D since it's a D3D12 game. I've heard that D3D12 VR games in general were problematic on Proton until fairly recently (like May of this year). The only problem is I'm having trouble trying to patch the latest bleeding-edge with the necessary patches to get Revive going (The Oculus Touch Demo did not work on the latest GE or bleeding edge, it required the patched proton from last year) |
|
Okay, so a few days back, I gathered a few patches from CrossVR's Proton fork, and from twhitehead's wine-valve input branch So on the bleeding-edge branch of upstream Proton (ValveSoftware/Proton@cb52083), the first problem is some files have been rearanged in the time these commits were made if I edit the patch files to redirect to the new location of the source file, the patch just ends up failing :/ So I'm sorta stumped on how I would apply these patches (besides maybe manually editing the files) |
|
Found my problem https://github.com/ValveSoftware/Proton/blob/proton_9.0/vrclient_x64/vrclient_main.c vrclient_main.c is dramatically smaller compared to how it was in Proton 8, like 1000+ lines smaller no wonder the patch didn't go through 😅 |
|
There was a pretty heavy rewrite of the Wine VR stuff to bring in into line with wine's newer cleaner split between the Windows and the UNIX side. This came out of, if I understand correctly, the desire to be able to run 32 bit Windows binaries with Wine using 64 bit Linux libraries. I did a rewrite for it, and rbernon (from CodeWeavers) and gofman guided we through getting it acceptable for upstream. It landed in Proton bleeding edge experimental on December 5, 2023. I checked a few of the changed files against the link you provided and they look like they are in agreement with the changes. Also looks like my commits are on that branch, so you should be good without any patching on this branch ( |
|
I will be sure to report my findings with Proton 9.0. I've only tested recent GE releases and bleeding edge, which while the Oculus Tuscany demo world works, the Oculus Touch demo doesn't. 9.0-3 should be a good candidate as the changelog included Should the touch demo still not work, something regressed, and I'll have to bisect |
|
Have been busy and haven't ran steam for many months, so updated it and gave my sample apps a try. Results were mixed. Both the OculusWorldDemo and the DX11 OculusRoomTiny example worked under Proton 9.0-3. Condor 2, however, does not. A popup says there was a failure to initialize the DirectX system. To dig into this a bit, I created the ~/.local/share/Steam/steamapps/common/Proton 9.0 (Beta)/user_settings.py file (from the sample one) and edited it to turn on after you click start. All of this makes me wonder if something is now failing between Revive and the newer Proton 9.0. |
|
Yeah, Proton 9.0-3 didn't work out for the touch demo |
|
After a late night of bisecting, with ValveSoftware/Proton@ae89737 being the starting good commit, this was my end result Currently ValveSoftware/Proton@c8669fbc is the most recent I've tested currently that works with the Oculus Touch demo. I'll keep testing for now |
|
okay, I've been going through the list of commits made to the So ValveSoftware/Proton@c8669fbc is still the last commit that functioned properly with Revive. Any commit past ValveSoftware/Proton@d8f44fe5 (which is the one the bisect pointed me at) failed to build properly. ValveSoftware/Proton@b911e63 fixed the compilation errors by updating the wine submodule, but it's also the one where Revive compatibility breaks again |
|
@BoofOof32 thanks very much for doing that! ValveSoftware/Proton@d8f44fe5 just adds |
|
with ValveSoftware/Proton@d8f44fe5 reverted, I was able to get up to ValveSoftware/Proton@9e60111 to work with Revive. Interestingly though, anything past that commit, testing ValveSoftware/Proton@ff94f04 and ValveSoftware/Proton@8f03470 lead to both Oculus World Demo and the TouchNUX demo to just sit in the background and not do anything. Not even the usual "Cannot run this application without an Oculus Rift" error |
|
@BoofOof32 Wow! Nice work. I only had time to test the first bisect in the middle of your range last night, but observed the same behaviour of the process just hanging. Condor 2 does give a bit more feedback though as the main menus don't use Direct X, the flight setup uses Direct X but not Oculus, and the actual flight uses Direct X and Oculus. This hanging is occuring on the flight setup. So it is indeed entirely different than the Oculus error, which only occurs once you start the flight. My thought is we should create a new branch starting at ValveSoftware/Proton@b911e63 and then interactively rebase it back to ValveSoftware/Proton@d8f44fe5 in order to re-arranging the ValveSoftware/Proton@9e60111 to ValveSoftware/Proton@b911e63 range that you have identified. We can move commits that we suspect are okay down to apply first on the last working commit ValveSoftware/Proton@9e60111 that you identified to verify that they are actually okay. We can also move commits that break compilation up to match the ones that fix their breakage (e.g., the warning to error one ValveSoftware/Proton@d8f44fe5 should probably go up to the very top to be right after the wine update commit). My guess would be it is either one of the OpenVR related commits or one of the submodule updates. The strategy then would be to separate these out. I would apply all the proton: and lstreamclient: commits immediately on top If all of this succeeds, then we are left with just the vrclient* commits to test. If it turns out there are all sorts of inter-dependencies that make this not work, we could instead try moving all the vrclient* commits down to apply first and hopefully be able to test them. |
|
Here would be the actual rebase. All the stuff that you just finished identifying as okay minus the wine-warnings-to-error commit which goes with the wine update I wasn't 100% certain if you meant up to and including this commit, in which case it should go here, or up to and not including it, in which case it should go down with the rest of the vrclient* commits followed by all the stuff that seems likely to be benign followed by the submodule updates and the wine-warning-to-error commit followed by the vrclient* updates |
|
I went ahead and created a Proton fork with a branch starting on ValveSoftware/Proton@b911e63. https://github.com/BoofOof32/Proton/tree/Revive It has been a while since I've managed a git repository, and I didn't get all that complex with it, so apologies if I get confused in some areas. |
|
I used up and down in my original note as if commits went latest to oldest. The first creates and checks out a branch called rebased starting ValveSoftware/Proton@b911e63. The second lets you modify all the commits starting at ValveSoftware/Proton@d8f44fe up to the checked out commit ValveSoftware/Proton@b911e63. Basically the interactive rebase is like a series of patches to apply. You can specify if you want to edit any of them, change the commit message, etc., and also just change the order. So reorder them as node above, save the file, and quit. Git will then go back to ValveSoftware/Proton@d8f44fe and apply them in the order specified from top to bottom. The commit hashes will change as the history will now be different, but hopefully it will bisect better (more of it will build) than the original in order to identify which one actually broke it. |
|
Tried a few orders. Seems the two critical commits are and Either by itself gives the DX hanging on flight setup. Both together give the initialization error on flight start. I guess the next thing to do is bisect the update wine (that is, bisect the wine submodule between the before update and after update commits) to see when the freezing happened and if it can be separated from the initialization failure. |
|
Sorry for the hiatus, I got busy with some other things and needed a break. I tried rebasing ValveSoftware/Proton@b911e63 to ValveSoftware/Proton@d8f44fe with this order it seems to have tripped over on applying the 2nd commit perhaps I applied in the wrong order? I did flip the order of picks you listed for the rebase |
|
Yeah. Pretty sure you can't flip the order as some of later ones likely do build on the earlier ones. Note too that when you go to bisect wine, you will want to apply this patch that causes it to always download the vulkan xml file. Without this it will stop building when you go back to before this file was added There are also a lot of intermediate commits that don't build. I found it best to just leave it running on a loop until it succeeds |
and others
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.
The text was updated successfully, but these errors were encountered: