Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
0 
Report this post
You're right to ask! We prioritise Linux development, and actually our Linux builds always come first - so of course VR on Linux is very important to us. Unfortunately, Steam have not always made this easy in the past, and even now their system does not fully support VR out of the box. Our engine does support the mis-named OpenVR in an entirely platform-agnostic way, and everything that's enabled on Windows is enabled on Linux for that.
So, we certainly do support VR on Linux as much as we support it anywhere else. However, we've not been able to get VR on Linux working at all on any of our development machines, so we've been unable to test it yet! Basic features such as powering the base stations on and off with bluetooth still don't appear to be possible with OpenVR; once they are, we're confident the gameplay experience with sphereFACE on Linux (and even macOS, if we're ever going to see that) will be identical to that on Windows.
If you have a working Steam VR setup we'd love to hear more about how you have that configured, and what you have to do differently. If you do get a chance to try the game out on Linux we can also guarantee you full support to make sure we get it working in VR - if you have an environment where any other game works with the OpenVR SDK, we'll do everything we can to make sure we can match that.
Did I mention we love linux?
Valves Linux "support" does indeed leave a lot to be desired. Right now, you can't even start SteamVR for Linux from Steam itself: http://steamcommunity.com/app/250820/discussions/5/1290690669223254313/
You can however start it (assuming everything else is configured correctly) from /home/<user>/.steam/steam/steamapps/common/SteamVR/bin/vrstartup.sh
Other than that, you will of course have to follow the instructions from here: https://github.com/ValveSoftware/SteamVR-for-Linux (Steam Beta client as well as SteamVR Beta, and the correct Nvidia driver as well - I'm on 381.22).
I'll test sphereFACE as soon as I can - hopefully later Today.
I'll give this game a try this weekend and see if I can get anything working.
Have you had a chance to revisit the idea of VR in Linux? Since our last chat in May, SteamVR seems to have become pretty stable in Linux.
We currently have a primary development workstation that is set up running Steam on Linux, and connected to a HTC Vive. However, SteamVR doesn't seem currently capable of turning on the base stations, which makes it seem to us not very consumer friendly - we haven't gone much further than this in terms of testing.
If you'd like to walk us through configuring the Vive with Steam on Linux and getting a working test environment, we'd be happy to revisit it.
Meanwhile, as far as we're aware, without having been able to actually test it, everything about the game should be able to support VR on Linux as-is - we use exactly the same code for all platforms, we load the dynamic libraries in the same way, and the runtime at least is detected on Linux the same as Windows. If you have a working VR setup on Linux, please give it a try and let us know if it doesn't work - we expect it to work fully if there's a working setup.
I don't remember there being any issues installing and using SteamVR? Did you check the requirements from github (see my earlier post)?
What doesn't work, exactly? Do you get any errors/error numbers?
The basestations not turning on automatically is a minor thing, I think (I do wish they would get it fixed, though). Unplug them and plug them back in, and it should work.
I've had some time to try to get SteamVR running on our dev machine again, with no success. The following is what I've done so far.
Fire up steam
Power on the Vive
Power cycle the base stations to make them wake up
Download SteamVR
SteamVR launches
"Connect Failed" - "A key component of SteamVR isn't working properly" error 307
https://i.imgur.com/XFW5d3p.png
Running ~/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrstartup
returns to prompt instantly with no feedback
Running LD_LIBRARY_PATH=./ ./vrserver
missing libudev.so.0
ln -s /lib/x86_64-linux-gnu/libudev.so /lib/x86_64-linux-gnu/libudev.so.0
ln -s /lib/i386-linux-gnu/libudev.so /lib/i386-linux-gnu/libudev.so.0
Running vrserver again: https://hastebin.com/zihazugepa.txt
returns to prompt
Try to launch SteamVR from Steam again
https://i.imgur.com/NbeI4mM.png
Error box cannot be closed, clicking on it does nothing
SteamVR windows also cannot be closed
Room setup appears but cannot detect the headset
Have to kill Steam from the term to restart it
Terminal log: https://hastebin.com/guwabijivo.txt
Opt into Steam beta, restart client
Opt into SteamVR beta
Launch SteamVR beta
https://hastebin.com/ugokogaqot.txt
https://i.imgur.com/NbeI4mM.png
Same error box as before, except error can now be closed. No room setup appears this time.
Running STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 steam
Have to log in again, interface takes several seconds to update between typing.
Same error as above.
Checked /lib/udev/rules.d/60-HTC-Vive-perms.rules, all configured correctly.
Running vrcompositor in gdb:
Xlib: extension "NV-GLX" missing on display ":0".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff74598b0 in vkCreateXcbSurfaceKHR () from /usr/lib/x86_64-linux-gnu/libvulkan.so.1
backtrace:
#0 0x00007ffff74598b0 in vkCreateXcbSurfaceKHR () from /usr/lib/x86_64-linux-gnu/libvulkan.so.1
#1 0x00000000004706bc in vr::CHmdWindowSDL::CreateVulkanSwapChain(SDL_Window*, unsigned int, unsigned int, vr::CHmdWindowSDL::SwapChainData_t*, VkSurfaceKHR_T*, bool) ()
#2 0x0000000000471582 in vr::CHmdWindowSDL::CHmdWindowSDL(vr::CHmdDistort*, int, int, unsigned int, unsigned int) ()
#3 0x00000000004497b2 in vr::CHmdDistort::Initialize(vr::CVRNotificationManager*, CVRSharedState*, void*, bool) ()
#4 0x0000000000474eb2 in CVRCompositor::Init() ()
#5 0x00000000004784c5 in RealMain(unsigned int, ParsedArguments_t&) ()
#6 0x000000000044036a in main ()
It just seems comprehensively broken at this point. Any suggestions for what to try next, or what I might be missing?
I actually had this same error back in February: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/16#issuecomment-284117052
I don't think I've had it after upgrading to Ubuntu 17.04.
Which distro/version are you using? (you mention that you symlinked libudev.. I don't think you have to do that on Ubuntu 17.04)
In any case, you could try uninstalling libvulkan1 and see if that helps. For some reason, STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 didn't work for me either.
Also - make sure you use a Nvidia driver that supports vulkan.
This machine is using the nvidia drivers installed through Debian, version 375.66-1, including the optional vulkan packages.
Removing the vulkan libs isn't really a practical option long-term as they are needed by a growing number of system components, but removing them temporarily to test yielded the following results:
http://i.imgur.com/7tQXubH.png
We now have error 306 instead of 307, but otherwise the same behaviour, and vrcompositor fails to start, due to failing to find libvulkan1.so.1 in any case.
The idea of (temporarily) removing libvulkan1 was to make sure it would use the SteamVR version. You're still starting Steam using STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 ?
Another note: The releaselog says: "NVIDIA cards require version 381.22 of the NVIDIA Driver or above". I know it worked with the 375 drivers earlier, but apparently they've changed the requirements?
If it was me, I would probably try installing and dualboot to Ubuntu 17.04, since that's what most people running your game in Linux would be using.
is that an option for you?
Otherwise, we could try asking in https://steamcommunity.com/app/250820/discussions/5/ . The (small) community of Linux users here have helped a couple of other devs out with their games on other occasions.
That might be an issue; unfortunately 375.66 is the latest available nvidia driver in Debian at present, and Debian strongly discourages users from installing the independent nvidia packages instead - I've encountered first-hand the countless problems those can cause whenever there's a new kernel version, so I wouldn't advise our users to switch away from the distro packaged version. If the newer version really is what's causing steamvr not to work, then we'll need to wait until their required version of the nvidia drivers becomes available in the mainstream distributions before we can expect any serious number of users to be able to run it.
According to the Steam survey, the majority of linux users are still on Ubuntu 16.04.
We can certainly try firing up a live-usb test environment with ubuntu, but ultimately we're looking to start from a situation where we can guide any potential user through the process of making VR run on their existing Linux setup.
Fundamentally, if the solution we suggest to "SteamVR doesn't work on my install" is "install a different OS and reboot into that", then they may as well just reboot into their Windows install (which the majority of our users have) where they'll know for sure VR works. So I'd like to avoid that if possible, and try to find or put together a generalised guide to get it working on any distro in any situation - and there should be no impediment, especially if it's an up to date setup such as Debian Testing.
Having gone through this process of troubleshooting today, my current conclusion is that even if it can be made to work for some, the vast majority of users can't be expected to set environment variables and remove vulkan and run the vr compositor in a debugger just to get their VR setup working; it seems to me like SteamVR on linux still isn't ready for public consumption.
It's come a lot further than when we last tried to make it work, but if we can't even get SteamVR running out of the box on our own dev machine without having to reboot into another distro, then it is probably not accessible to many other linux users for similar reasons. Then it seems like only a very tiny minority of users - who fall at the intersection of owning the right VR hardware, and having the right linux setup, and having the technical skill and patience and time to debug it all and make it work - will even be able to try our game in VR on linux at this point.
Unfortunately it's probably not worth our developer effort to look into this further until Valve improves the stability and availability of SteamVR in general, and especially on linux. We'd be spending dozens of man-hours debugging something that only one or two people would even be in a position to play. Once Valve have a press-play-and-it-runs solution that works for the majority of linux users, I'll be happy to revisit this - or sooner, if anyone is able to suggest a simple guide to make it "just work" in the meantime.
The issue is not with the stability of SteamVR. As mentioned, it's actually fairly stable now. I would even say that it "just works", once the prerequisites are in place - just as in Windows.
Apparently, in your case, the issue is that you're just not using a supported video driver. For Linux uses, stuff like that is not even regarded as an actual issue. You just install it and move on. Windows users are prompted to install new drivers all the time to fix an issue or add new features or stability.
My goal here was to make you guys able to run SteamVR, so you could work on providing Linux users a version of your game that was on par with the Windows one - including VR support. You asked me to, remember? Installing a video driver really shouldn't be a showstopper.
Anyone who would buy your game for the VR support would of course have SteamVR up and running first. If for some reason they had not, You would just need to ask them to get that fixed first. It wouldn't be your problem - not matter what distro they chose to use.
(you know this - VoxelStorm actually replied to this guy saying just that: http://steamcommunity.com/app/485680/discussions/0/1290691308572046696/)
In case you're wondering.. yeah - I'm a little cross.
I will of course be asking for a refund for the game.
If SteamVR were fully supported, this would not be a discussion we'd be having. The problem is simply that we can't even get SteamVR to run on Linux - and when asking for help, you yourself just replied with:
So what exactly is it you expect us to do?
The fact that there are dozens of threads on Steam, and many more elsewhere on the internet, taking dozens of steps to try to get it working for any user, makes it clear that we're not the only ones having problems. You yourself made it clear that we should expect it to only work with a specific release of Ubuntu, and went as far as suggesting we dual-boot into a different OS just to try to get it working.
Comparing this to windows is not applicable; in this case, the driver *is* the latest available in Debian. Installing the driver outside of Debian is guaranteed to cause a complete failure the following kernel update due to incompatible DKMS modules, and nvidia's installer clashing with the way Debian handles DKMS modules for upgrades. We've seen this before. Upgrading to the latest Windows drivers is a reasonable thing to ask, as it breaks nothing. Going outside of the package management to install Nvidia drivers guaranteed to leave the system with a non-working graphical environment next kernel update is not at all similar, and even if we do it with our own dev machines, we could never advise our users to do likewise.
Furthermore, there's no indication from the errors that the video driver is the cause of the problem. Other threads about these problems online suggest a video driver earlier than the 375 we're using, but a development-only version from Nvidia's site. Again, perhaps you'll tell us that telling our users to install a special development-only driver release is a normal requirement to have to play our games. But this indicates that the driver version is not at all the problem, which makes it clear that it's not at all as simple as you make it sound.
Yes, we asked for any advice on how to walk through any user - including ourselves - through the process of getting SteamVR running on a typical Linux install. So far we've been told to remove vulkan drivers, install a graphics driver not yet officially supported by Debian and guaranteed to cause a failure of the X system next time we reboot after a kernel upgrade, and finally to dual-boot and install a different operating system entirely. I'm afraid that these really are showstopper pseudo-solutions - they don't solve the fundamental problem at all, in that we should be able to expect a typical linux user to run SteamVR without having to break their existing linux install, or have to install an entirely new distribution.
The problem is that our code supports the API, as written. The OpenVR system is dynamically loaded and linked at runtime on linux correctly, as it is on windows and even macos. Nothing is different in our rendering pipeline between those operating systems, and the fact that it works perfectly in VR on Windows - and everything that we're able to test (i.e. everything except VR) on Linux also works perfectly there - strongly implies to us that there is no fault in our software to fix in the first place.
We're very keen to investigate and see if we can reproduce the fault you described - but chances are that the bug is a limitation of OpenGL support in current SteamVR on Linux; according to Steam's own documentation, "OpenGL applications are currently too slow to use interactively; only the Vulkan Submit path is optimal". This limitation of Valve's runtime, along with the many issues we (and the majority of Linux users) are having in even getting SteamVR running in order to test our software, put a huge external limiting factor on what options we have to achieve this. We have no choice but to conclude that it's simply not yet fit for consumption; we have always promised to support SteamVR on Linux when it actually works properly on Linux, and our evidence is that it simply does not at this point.
We're sorry to hear that. However, in context, you are asking us to chase bugs in Valve's software, make numerous reboots to install multiple versions of graphics drivers and even install a new operating system, just to try to test software on a setup that Valve themselves have not finished, is not officially supported yet and does not seem to run on 9/10 of Linux setups without heavy tinkering. There comes a point when it becomes an unreasonable request.
As Riot stated above, when SteamVR support improves - hopefully soon - to the point that it can actually be run from Steam by a regular user (or even one of our dev team!), we'll be very happy to revisit this and look into it further; although without full OpenGL support in SteamVR's direct mode on Linux, I doubt any of our existing games will be playable in that context anyway - again, due to a limitation of that runtime implementation rather than our own software.
Similarly, if you or anyone else is capable of putting together a simple guide that can walk both us and regular users through the process of getting SteamVR working on a typical Linux install without requiring a specific version of Ubuntu to be installed, or requiring update-breaking video drivers, then we'll be very happy to revisit this issue again then. Meanwhile, I think we've already done as much as can reasonably be expected at this time, considering Valve's runtime simply does not work as expected.
I've never seen so pathetic a moaner! U should feel lucky, these devs r bendin over backwards to help you and your obscure lil setup. How many other devs even try to fix somethn like this where its obvs volvo's fault and not theirs? Theyre on your side, trying to make linux vr possible, and ur just doin wat u can 2 make their day as bad as u can. What's ur problem?
I guess u'll also then be gettin refunds from all the other games u have that support linux vr with own opengl engines, o wait, i bet there arent any others r there?
You said: "If you do get a chance to try the game out on Linux we can also guarantee you full support to make sure we get it working in VR - if you have an environment where any other game works with the OpenVR SDK, we'll do everything we can to make sure we can match that.
Did I mention we love Linux?"
I do have an environment where it works - and I tried to help you get yours working, too, because you asked me to. According to your own post, you would then "do everything you can to match that", and guarantee me full support to make sure you get it working in VR.
In reality, you weren't even willing to install the driver mentioned as a prereq for a working SteamVR environment. My "I don't know, tbh" came from thinking that you had all prereqs in place, so I didn't know what the problem could be. It's very easy to tell from the context.
I (almost) only play VR games now. I bought your game in order to help you get it working in Linux - for me and other users.. There aren't a lot of them, and you guys seemed genuinely interested in making it work (we guarantee you full support / We will do everything we can do to make sure we can match that). As it turns out, you are not, and I won't be playing the game in 2D. That's why I'm refunding.
I'm not going to waste any more time on this. Good luck with your game.