please show Linux some love :)

[EndeavourAccuracy]

Some of us would really like to start using our HTC Vive headsets, and we have no idea how long we'll still have to wait until Linux support arrives.

Maybe ask HRM/CEO to hire one or more additional people to focus on getting Linux support up and running?

Two days from now it'll be 4 months since the release date...

[sduensin]

This is the sole reason I run Windows on my system. :-( Gaben, save me!

[kkriehl]

For me this gets more important with the unavoidable Anniversary Update, which irrevocably reactivates some or all things I disabled after buying and installing Windows 10 Pro for my Vive (shop, telemetry, apps, ads - this is the first Windows OS for me since 2007 and I feel like I have a dormant virus in my PC). I can already develop games and experiences under Linux with Unity 3D, but still not for my Vive... I, and many other people, bought the Vive over the Rift also because of the promised Linux support.

Please stabilize at least the neccessary drivers and port the SteamVR plugin for Unity 3D. Even if we have to develop the first (simple) games ourselves!

(It hasn't been that difficult to get the HelloVR sample application compiling and running for me with @ChristophHaag's fork and the openvr-git and vive-udev packages from Arch Linux's AUR repository, but sadly the tracking of the HMD doesn't seem to work yet and my Vive isn't recognized correctly by vrcmd with SteamVR beta)

[ChristophHaag]

It also hasn't been that difficult to "port" as they clearly started porting it to linux (had some #ifdef __linux__ etc already in the codebase), it just uses a couple of windows-only functions that actually have *nix equivalents and it needs a build system and that's it. Which raises the question why nobody at Valve has done that in well over a year since this issue was opened: #10

[Plagman]

We are working on it but it's not done yet. There's also new features that need to be brought up in order to SteamVR to run on Linux that we're working towards enabling in collaboration with Khronos and their various hardware vendors.

[Cheeseness]

Thanks for the information, @Plagman. I had suspected that this was the situation, but it's nice to have confirmation.

As a developer who is Linux based and has had VR projects waiting in the wings since 2013 (and as someone who's not convinced that direct rendering was the right thing for vendors to pursue so early in the current generation of VR hardware), I feel disappointed about being left behind.

[shazow]

Is there anything we can do to help speed this up? Test early builds? Fix bugs in OSS portions?

[aronschatz]

I'd also like to throw my support in. Any type of VR support on Linux (even just in testing) would be great. Having to use Windows to build VR games and such is not ideal as Linux is what my primary use was going to be for SteamVR, even for building games.

I'm sure most of us would be happy to help test anything in it's current state, too.

[undefinedMethod]

Second the sentiment on testing. To have anything even at the cost of
severe migraines would be great. The knowledge that then the project would
be in the hands of talented open source developers to work on would surely
speed up progress.

On 4 Aug 2016 2:13 p.m., "aronschatz" [email protected] wrote:

I'd also like to throw my support in. Any type of VR support on Linux
(even just in testing) would be great. Having to use Windows to build VR
games and such is not ideal as Linux is what my primary use was going to be
for SteamVR, even for building games.

I'm sure most of us would be happy to help test anything in it's current
state, too.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#213 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACMwZCgKv4MCVNZJLzZB0EJCQwLLYoEGks5qceV0gaJpZM4JcCnE
.

[mncharity]

It seems two distinct questions/topics are sometimes blurred:

(Q1) Getting Steam to play VR games on linux. The challenge here seems to be the compositor. "When?" has long been answered by Valve, as by @Plagman above, by "We are working on it but it's not done yet."

(Q2) Getting HTC Vive to work on linux. For example, "when will it be possible to pair controllers on linux?" The challenge here seems more likely to be Valve resource prioritization, than technical difficulty. I've not seen Valve comment on this. But I've not yet seen them clearly asked.

What opportunities might exist?

Regarding (Q1) Steam, I haven't seen mention of a way for the community to help. It might be an interesting discussion to have. For example, is there an opportunity to improve the SteamVR build architecture on linux? Other companies have suffered with big monolithic proprietary blobs, struggling with linux compatibility, and then found happiness with a smaller proprietary blob, plus an open source glue layer. So the community can just fix glue, rather than attempting reverse-engineered kludges. The SteamVR files suggest low-hanging fruit exists (for example, a bash script corrupted by DOS line breaks, and constrained to run from a single directory). Log errors suggest Steam itself could use a helping hand. On the other hand, community contributions are often hard to come by.

Regarding (Q2) Vive, there seems an opportunity for greater community communication. There's Arch wiki, and scattered blog posts and discussion threads, and github forks. But...

But for instance, when I "Play" SteamVR, it briefly flashes a window and then crashes. Does it do that for everyone? Does Valve have some internal integration server where it actually runs? Do you know? When it partially improves, will you notice? There seems an opportunity to better document the state of play.

And for instance, there are several stacks (openvr, osvr, driver_lighthouse, janusvr, etc), often flakey, and with out-of-date cookbooks. For each, is your recent attempt partially not working because that bit just doesn't work yet? Or it's your hardware? Or you missed a step? Or there's a transient breakage? Or a longer-term regression? You don't know.

Or consider driver_lighthouse.so. Doc-Ok reports having HMD and controller tracking working. Lacking source, I reimplemented it, but my controllers don't work. But I do have a SDL2 stub, to permit HMD tracking on a different machine than the HMD HDMI, and a very limited WebVR mock. But I don't know of a good place to discuss it, determine interest, or collaborate.

Perhaps it might help to have a github wiki? Or /r/Vive wiki page?

[undefinedMethod]

I think communication here is the key. What little there is of it is not worthwhile. Perhaps Valve's 'we're working on it' replies were OK at some point in the past but these days they seem almost old fashioned. You can view an Unreal engine trello board and get a sense of their priorities and current tasks. Just something even in the same ballpark as this for the work on VR plugins for Unity and Unreal would satisfy the demands of the curious.

Its just my opinion but Valve finds itself stuck in limbo with a policy that seems to promote the use of open source technologies but with a totally contrasting closed source attitude to communications.

[ghost]

There's also new features that need to be brought up in order to SteamVR to run on Linux that we're working towards enabling in collaboration with Khronos and their various hardware vendors.

Valve may not be talking much, but it seems pretty clear to me what's going on.

At SIGGRAPH 2016, it was announced that VR support was a priority for Vulkan Next.. This includes support for Direct access to displays, and I'm guessing/assuming this is the same Direct mode used with VR displays, which is probably one of the 'new features' Valve is looking for.

NVIDIA's Windows drivers have had support for Direct Mode for awhile now, but I don't believe this support has translated over to NVIDIA's Linux drivers yet. (Correct me if I'm wrong, also not familiar with AMD driver situation but I believe it's the same.)

So, in short, I don't think the software tech is quite there yet for a good Linux VR experience, and I think this is why Valve has been holding out on Linux support. They're trying to work with these other companies (Khronos, NVIDIA, AMD, etc.) to get the desirable features for good support in place.

It could be that related NDAs with other companies prevent Valve employees from commenting much on the subject at this time. Or it could just be poor communication as of late. But clearly Valve is dedicated to getting VR on Linux (as a part of supporting VR on SteamOS as well), I think it's simply a matter of having some patience at this point.

EDIT: Just for some minor clarification, I might add that I don't think many people working on VR right now consider Extended Mode a 'good experience' due to the strict performance requirements of VR. In reverse, I think companies like Valve may very well consider Extended Mode to be an unacceptable experience for such expensive hardware, and thus they'd rather not support a platform at all than have support for only Extended Mode.

Also, after skimming through this document, it seems clear that there may be some other features such as asynchronous timewarp that they're working on getting up-and-running in Linux as well.

[EndeavourAccuracy]

@sn0w75 I think you may be right. If there are "new features" required, and Valve is "working towards enabling [these] in collaboration with Khronos and their various hardware vendors", then that sounds like an extension of the Vulkan specification. And since Tom Olson mentioned direct screen access as one of the priorities for Vulkan Next, what other conclusion can we draw at this point than that we'll have to wait until Vulkan Next arrives?

[ghost]

@EndeavourAccuracy As of one year ago, Direct Mode for VR was only supported by DirectX11 (no OpenGL or DirectX12 support), and I'm not sure that situation has changed much since then. (I don't own a VR headset yet and I don't run Windows, can anyone confirm this?)

if you look at the NVIDIA article from my previous post, they mention OpenGL and Vulkan support as a future work items (for NVIDIA to cover), so I'm pretty sure the lack of Direct Mode support in OpenGL is rooted in the lack of an OpenGL extension provided by the graphics card driver rather than lack of/slow development on the part of Khronos.

In other words, the drivers have to support this stuff before the Vulkan or OpenGL APIs can support it, although Khronos will probably work in tandem with NVIDIA/AMD to roll out updates for both the API(s) and graphics card drivers at roughly the same time as they did with the Vulkan API and new graphics drivers that supported Vulkan.

So in short, I would be looking out for updates for the Linux closed-source graphics card drivers provided by NVIDIA/AMD as well as Vulkan Next news and/or OpenGL spec update/new NVIDIA or AMD driver extension/etc. news. I think that's about all I can 'conclude' (I can't predict the future and I don't work at NVIDIA/AMD/Khronos/Valve, after all).

The only other thing I might add is: it seems that Valve is also working in tandem with Khronos on this stuff, so we might see updates for NVIDIA/AMD drivers, Vulkan/OpenGL API updates for better VR support, and Linux OpenVR support all happen at roughly the same time ('roughly' being perhaps a few months difference if some part is lagging behind the rest).

[Krovius]

@EndeavourAccuracy As of one year ago, Direct Mode for VR was only supported by DirectX11 (no OpenGL or DirectX12 support), and I'm not sure that situation has changed much since then. (I don't own a VR headset yet and I don't run Windows, can anyone confirm this?)

@sn0w75 OpenGL support has been added since (verified in my own project).

Still nothing for Vulkan/DX12.

nVidia drivers have an extension to pass textures between Vulkan/OpenGL making VR possible with Vulkan as a workaround.

[jtsiomb]

There are no technical obstacles, "direct mode" works on GNU/Linux under X11 since for ever due to the excellent X window system architecture. Special driver support was necessary only for windows, the rest are marketing keywords.

I have written an article on how to set up the Oculus DK2 under X11 as a separate screen, more than a year ago: https://codelab.wordpress.com/2015/04/02/proper-oculus-rift-dk2-setup-on-gnulinux/

[ChristophHaag]

All that aside, there is no real reason SteamVR should even require direct mode. Even if the developers think they should have something like that, an interim solution could still be just rendering to a normal fullscreen window and switching to direct mode later whenever everything is there on linux.

In fact, SteamVR on Linux does this right now. A couple of days ago I tried hellovr with my OSVR HDK2 and it displays the SteamVR compositor in a window:

The problems are:

• It's not fullscreen
• Distortion correction is only on the preview window, not on the compositor window
• It's super laggy

But since it is already in this state I do not believe that a good programmer couldn't make it at least usable in a couple of days.

The much bigger problem is Unity, Unreal etc. support. Before application developers are releasing Linux versions of their applications, the upstream Engines must provide them this Linux support.

[Cheeseness]

In fact, SteamVR on Linux does this right now. A couple of days ago I tried hellovr with my OSVR HDK2 and it displays the SteamVR compositor in a window:

I can confirm. I had similar experiences earlier this year with my Vive and @ChristophHaag's OpenVR tweaks (I didn't notice significant lag though).

The much bigger problem is Unity, Unreal etc. support.

So far as I'm aware, those engines are using OpenVR for SteamVR support anyway (whether directly or via a third party plugin), so "official" vendor provided support for the device is still a blocker there. FWIW, I know developers at Unity who would be happy to look at Linux VR support as soon as that's available.

[ghost]

@jtsiomb Feel free to correct me if I'm wrong (you may know something I don't).

My understanding of Direct Mode is that the GPU renders directly to the display rather than going through a compositor, which allows for some performance boosts and resolution of issues specific to Windows (confused display destinations for desktop applications) and at least one minor issue that may not be exclusive to Windows (support for standby mode when HMD is not in use).

Setting up a HMD as a X screen works, but technically still goes through the X11 compositor. In the case of fullscreen applications, however, the compositor shouldn't have to worry about anything else on the screen, so any 'performance boost' from subverting the compositor should be negligible. And of course, X doesn't have issues with display destinations like Windows may have. So I agree that the setup of a HMD as an X screen ought to work pretty well for running VR applications in Linux right now, and it seems like OpenVR could work with this setup without much additional work as @ChristophHaag has described.

Due to the low latency demands of HMDs, I think there are some desirable features, such as getting a high-priority graphics context for timewarping a rendered image before display, that will need new features implemented in Linux graphics drivers to work. While these features and Direct Mode aren't 'essential' for making VR work in the most basic sense, I think companies like Valve probably want these features for their HMD's default experience, and thus are still holding out on OpenVR support in Linux until these features are ready, regardless of the fact that it could function pretty well in X with just a bit more work.

[jtsiomb]

@sn0w75 You are mistaken. If you have a compositor running on X11 (which is by no means a necessity), when any window goes fullscreen (as it should to display correctly on an HMD), the compositor leaves it alone to draw directly on the display.
But even if we assume that some compositor you happen to be using isn't doing that (which would really be a bug in the compositor), you can easily just disable the compositor manually before running a VR program.

The point is, there's no missing functionality here. Everything we need for low-lattency VR on X11 is already in place. There are no excuses.

And yes, of course even if we were missing something, it would be preferable to have something that works even in "extended mode" rather than nothing at all. But again, we aren't missing anything, and we can have great VR applications on GNU/Linux with X11 right now. Indeed, I do have that right now with my DK2 and the old oculus driver 0.5.x which was the last GNU/Linux version they released. It works great, and I use it for my VR projects all the time.

[Alan-Python]

Date: Tue, 16 Aug 2016 07:30:25 -0700
From: [email protected]
To: [email protected]
Subject: Re: [ValveSoftware/openvr] please show Linux some love :) (#213)

@sn0w75 You are mistaken. If you have a compositor running on X11 (which is by no means a necessity), when any window goes fullscreen (as it should to display correctly on an HMD), the compositor leaves it alone to draw directly on the display.

But even if we assume that some compositor you happen to be using isn't doing that (which would really be a bug in the compositor), you can easily just disable the compositor manually before running a VR program.

The point is, there's no missing functionality here. Everything we need for low-lattency VR on X11 is already in place. There are no excuses.

And yes, of course even if we were missing something, it would be preferable to have something that works even in "extended mode" rather than nothing at all. But again, we aren't missing anything, and we can have great VR applications on GNU/Linux with X11 right now. Indeed, I do have that right now with my DK2 and the old oculus driver 0.5.x which was the last GNU/Linux version they released. It works great, and I use it for my VR projects all the time.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.nfnfnhnhndfbdbh v vcchcbvc bbhbvcb fbhdfnb vjnfvjmnvb fnb ssebehnebe v cnhnfbb gdfn bfbfnhjfbvbgnbhb b bbgv nbg n

[DataBeaver]

It would be relatively easy to hack around the broken compositor. I can place my application window on the HMD screen and render to it myself, just like I do with the Rift DK2. The method IVRSystem::ComputeDistortion provides the necessary texture coordinates for rendering distortion on the client. A bigger issue for me is the lack of tracking, without which the VR experience won't be that different from a large low-res monitor. According to the vrserver log it can see the base stations and measure distances to them, but WaitGetPoses insists that none of the poses are valid. Tracking results indicate TrackingResult_Running_OK for the HMD and one base station, TrackingResult_Running_OutOfRange for the other base station.

[EndeavourAccuracy]

@DataBeaver
Short article about Collabora's efforts to analyze data from the base stations.
http://www.vronlinux.com/articles/collabora-is-analyzing-vives-lighthouse-signals.26

[shinyquagsire23]

@jtsiomb I've personally had issues with the DK2 and Linux but they're fixable if you patch the binaries, although it's questionable whether that should have been needed or not. I do hope that Vive support comes to Linux soon though, I want to get one but no Linux support is a deal breaker for me both with the Vive and the Rift.

[ChristophHaag]

Here is a blast from the past: http://arstechnica.com/gaming/2013/09/gabe-newell-linux-is-the-future-of-gaming-new-hardware-coming-soon/

Three years ago this was the prediction:

"I think we'll see either significant restructuring or market exits by top five PC players. It's looking pretty grim," he said. "Systems which are innovation-friendly and embrace openness are going to have a greater competitive advantage to closed or tightly regulated systems."

How true has this been?

Let's be honest, VR is a 99.9% Windows-only industry. Not even Razer and Sensics feel that they need to hurry to bring full Linux support to their OSVR platform. And why should they, most of their customers buy the OSVR HDK2 in order to play Windows-only SteamVR games.

In that sense Oculus and Valve are the two companies who are the most responsible for this situation.

Here is an example of what a developer of a game that is bundled with the OSVR HDK2 says: https://www.reddit.com/r/OSVR/comments/50iwuu/so_about_those_games_bundled_with_the_hdk2/d7oy44y

This is the damage that prolonged platform exclusivity does. Developers who are serious about "Linux-first" just stop or don't even start to make VR applications. Developers who are willing to make a Linux Version but view it as nice to have, drop it and keep developing in their windows-only bubble. Nobody wants to go back over years of work to check whether everything they've done works properly on Linux. Therefore many simply won't.

This github issue actually gives me flashbacks to the Oculus Rift DK2 situation. Back then they released their 0.4 SDK with a windows-only proprietary tracking solution. This is one of the more popular threads where people complained about the situation: https://forums.oculus.com/community/discussion/10939/lets-make-a-sdk-0-4-linux-nagging-thread

And then Collabora Reverse Engineering the Lighthouse tracking mirrors Doc-Ok reverse engineering the Oculus Rift DK2 tracking back then: http://doc-ok.org/?p=1095

Newell has previously promised to unveil a Linux-based "Steam box" to compete against living room gaming consoles sometime this year

Playstation VR will be released soon and there is still no sign for SteamVR working on Steam Machines. Has Valve scrapped the idea of competing with consoles?

"It feels a little bit funny coming here and telling you guys that Linux and open source are the future of gaming," Newell said. "It's sort of like going to Rome and teaching Catholicism to the pope."

Considering that Valve's proprietary SteamVR is one of the major factors that are delaying VR from coming to Linux, it should feel a little bit funny in retrospect.

For the better part of the last two years I had a VR HMD laying on my table right next to me. I have yet to buy a single VR game. (I only put some money into the Apollo 11 kickstarter campaign, but still haven't seen it).

How long will it be until I can start to spend money on VR games in Valve's store? I want to give you guys my money, but there is literally nothing for me to buy...

[Balderick]

Many titles have had vr support added which means you probably have games in your library with can run in vr mode. Games like Team Fortress 2 are free to play and things like webvr and cardboard supported 360 videos etc etc all give the opportunity to access vr content with little more than a hmd and internet access.

Three years ago another gaming platform was announced. It is Linux based but is not Linux. It is not a gaming optimised or gaming focused platform though it does support vr and gaming. Software solutions like geforce now, revive, vridge and the like mean it is possible to enjoy pc spec vr content, gaming and media without a pc.

Android is the most under rated gaming platform there is. Devices like the nvidia shield android tv and razer forge are hugely under estimated imo.

Comparing steam machines to nvidia shield platform is night and say. Same day releases and huge developer interest is being shown on nvidia shield platform. Steamos can not make that claim.
Imo nvidia achieved everything valve said steam machines were going to bring to pc hardware with their nvidia shield console with nvidia tegra x1 onboard.

PC titles being ported to android and made available through Google play store is a growing trend as is mobile games being ported to pc. This already makes android a better option to consumers than Linux.

[aronschatz]

I think what we're all saying in different ways is that the community is willing to help offload (a great deal/most of) the work to get VR and Linux playing together. Even Unity brought OpenVR support to their Linux build (I'm still unsure of what that exactly means, though).

The pieces are there, the community is more than willing to throw resources at the problem, collectively. Just let us have access to the proper documentation and specs and let the community work its magic.

I'm working on two games for SteamVR and wanted Linux support on Day 0. I'm still planning on Linux releases, but without Linux build support, I just can't. I will stress again that developing on Windows is not ideal since Linux has been my primary OS for ten years. Even getting Linux development support is a great start.

[ChristophHaag]

@Balderick I don't really know what you mean, but I can say this.
I first run hellovr, obviously working:

Without changing anything, I then run team fortress 2. VR theater mode is disabled in the settings (doesn't exist on linux anyway), command line parameters -console -vr are added.
Clicking on VR Mode only gives error 108: HMD not found as a result.

I believe that the VR code in Team Fortress 2 is simply not working on Linux.

There's also the Dota 2 spectator DLC that is running on Valve's own Source 2 Engine (right?) and it's only available for Windows.

I had tried firefox nightly's webvr implementation for OSVR and that always crashes quickly, but that's not Valve's fault. Your post gave me the idea to try firefox nightly's openvr support, but it doesn't seem to work either. SteamVR doesn't like it:

Di Sep 27 2016 02:59:57.231339 - vrclient startup with PID=13574, type=VRApplication_Scene, config=/home/chris/.local/share/Steam/config/
Di Sep 27 2016 02:59:57.231570 - Unable to load driver lighthouse from /home/chris/.local/share/Steam/SteamApps/common/SteamVR/drivers/lighthouse/bin/linux64/driver_lighthouse.so.
Di Sep 27 2016 02:59:57.232026 - Could not create interface in driver oculus from /home/chris/.local/share/Steam/SteamApps/common/SteamVR/drivers/oculus/bin/linux64/driver_oculus.so.
Di Sep 27 2016 02:59:57.232441 - Could not create interface in driver oculus_legacy from /home/chris/.local/share/Steam/SteamApps/common/SteamVR/drivers/oculus_legacy/bin/linux64/driver_oculus_legacy.so.
Di Sep 27 2016 02:59:57.246939 - Starting vrserver process: /home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrserver
Di Sep 27 2016 02:59:57.250352 - Unable to create shared mem to get port number for pipe VR_Pipe.
Di Sep 27 2016 02:59:57.350541 - CIPCPipe::ConnectPipe(VR_Pipe) attempting bind to 51279
Di Sep 27 2016 02:59:58.306710 - Received success response from vrserver connect
Di Sep 27 2016 02:59:58.307029 - [Chaperone] No chaperone data. /home/chris/.local/share/Steam/config/chaperone_info.vrchap does not exist
Di Sep 27 2016 02:59:58.307139 - Unable to create shared mem to get port number for pipe VR_Compositor.
Di Sep 27 2016 02:59:58.321936 - Starting vrcompositor process: /home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrcompositor
Di Sep 27 2016 02:59:58.325426 - Unable to create shared mem to get port number for pipe VR_Compositor.
Di Sep 27 2016 02:59:58.425595 - CIPCPipe::ConnectPipe(VR_Compositor) attempting bind to 53867
Di Sep 27 2016 02:59:59.271911 - select failed on reading socket: errno=4
Di Sep 27 2016 02:59:59.271971 - GetNextMessage failed while waiting for message of type VRMsg_CompositorConnectResponse on pipe
Di Sep 27 2016 02:59:59.271976 - Invalid response to connect message. Connect failed

Again, the hellovr example still works.

all give the opportunity to access vr content with little more than a hmd and internet access.

And exactly that is not true currently. Additionally to a HMD and internet access you need to install Microsoft Windows on your computer.

[ChristophHaag]

Looks like they've killed SteamVR again:

/home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrcompositor: symbol lookup error: /home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrcompositor: undefined symbol: VRCompositorSystemInternal

So there are no automatic tests run on linux before a SteamVR update is distributed?

[Balderick]

@ChristophHaag aah my bad. It is sad but true vr content on pc really means vr content on windows.

Some users on windows report that simply ignoring the steamvr errors and warnings or simply closing or cancelling them will still allow TF2 to run in vr mode without using the -vr flag. You need to change graphics settings to activate vr from in game menu and restart.

It is not optimised for Vive but just simple head rotation first person . No positional tracked devices just the gyro rotation for hmd afaik a bit like Elite Dangerous's implementation which is a simple enjoyable seated vr experience.

My guess is TF2 vr support is the remnants of occulus and valves collaboration before oculus sold out to FB.

You need to run webvr content through a configured osvr server for your vr hardware as webvr natively supports osvr and not steamvr or openvr.

You should be able to access all of http://store.steampowered.com/search/?term=vr&os=linux either with or without osvr software depending on the vr devices/ hardware you are using.

Gaming on Android, googlevr and using arm devices to access windows steamvr apps through vridge and other third party apps seems to be a big thing in android land. I personaly truly believe there will be arm devices running steam for arm with full steam client feature support PLUS additional super duper next gen stuff soon, like very soon ...

[shinyquagsire23]

@ChristophHaag The only time I've had VR Mode in Steam work was when DK2 still had Linux support, after it lost support stuff still worked for a little bit but eventually broke more and more progressively.

[Balderick]

Wow I had no idea things were as bad for you guys. Unity having no Linux support and being used as main steamvr demo platform does not make sense at all if Linux was being made to be a realistic option for pc gamers.

Three years ago I was totally onboard the steam machine hype train. Valve seem to have totally pulled the plug. Something tells me they have been quiet for too long though, I suspect and hope some big news will be coming soon.

I wonder how many steamos users buy a vive and a game listed as supported for vr after searching steam store using vr and steamos search filters. http://store.steampowered.com/search/?term=vr&os=linux

i know I would be feeling let down when I discover steamvr is not even implemented in steamos or linux if I did

[ChristophHaag]

The thing is that Valve wanted linux support from the beginning, they even had the SteamOS icon on the Vive preorders. Just before the launch they decided they did not want to spend the money to actually make the linux support:

I've seen at least a couple of people who preordered it and apparently didn't check whether something changed before it shipped, for example here: https://steamcommunity.com/app/358040/discussions/0/351660338698372108/
But at least now people can see that it is a windows-only device before ordering, at least when they order from steam.

This is Valve's old unity plugin. https://www.assetstore.unity3d.com/en/#!/content/32647
It had that line from the very beginning:

Supports DX11 on Windows 7 and up
(OpenGL on Mac and Linux coming soon)

They just never spent the money to actually do the development. Now it is deprecated and unity has built in support for OpenVR and as far as we can see there is still nobody actively working on it.

[Balderick]

I find it interesting that Unity supports GoogleVR https://developers.google.com/vr/unity/ and have to say am finding myself wondering; "When will there be a steam for arm client available to download in Google play store?", more and more each passing day!.

[Cheeseness]

Unity having no Linux support and being used as main steamvr demo platform does not make sense at all if Linux was being made to be a realistic option for pc gamers.

For whatever it's worth, I know devs at Unity who are excited to get to work on adding Linux SteamVR/OpenVR support (Valve's plugin has been more or less superseded by built-in support within the engine) as soon as it's ready.

[Balderick]

That is good to know. 😀

[Conzar]

@Cheeseness What VR library are the Unity devs working on for GNU/Linux? Will they be adding OSVR support or creating their own VR library?

[Cheeseness]

@Cheeseness What VR library are the Unity devs working on for GNU/Linux? Will they be adding OSVR support or creating their own VR library?

I haven't looked into it in detail since Windows doesn't interest me very much, but I am under the impression that Unity's VR support on Windows (which they call "native VR") uses SteamVR, so I'd expect eventual Linux and Mac support to do the same.

Note that Unity devs are not currently working on VR support for GNU/Linux - I said I knew Unity developers who were excited about being able to if/when vendor support for these devices gets off the ground.

[Conzar]

@Cheeseness well, the unity devs won't be able to do anything for GNU/Linux if they are using SteamVR as SteamVR is currently not supported under GNU/Linux. There is an OSVR Plugin for unity, but I think there are problems.

[Balderick]

How strange. Absolutely no Linux build info and yet there is android project build info. https://github.com/OSVR/OSVR-Unity/blob/master/GettingStarted.md#building-for-android

[Cheeseness]

@Cheeseness well, the unity devs won't be able to do anything for GNU/Linux if they are using SteamVR as SteamVR is currently not supported under GNU/Linux.

Yes, this is what I was attempting to say.

There is an OSVR Plugin for unity, but I think there are problems.

The OSVR Unity plugin (like Valve's Vive plugin) is a third party developed/published asset. It's not relevant to the kind of engine level support I was talking about.

I don't know of any plans to add engine level OSVR support, and I suspect they will just stick with using the same APIs on all platforms and wait for SteamVR to get stable Linux/Mac support (note that there is also a SteamVR driver for OSVR that exposes OSVR devices via SteamVR's API)

[Balderick]

Hold on,. unity does not support linux so steamvr tutorial and other steamvr assets will not work in Linux. Steamvr apps will still run through linux but through openvr and not directly through steamvr. This is where osvr should come into play.

Though the arch wiki for vr seems to indicate all pc games in vr mode is broken in Linux https://wiki.archlinux.org/index.php/Virtual_reality

The vive should still work on Linux with Linux apps in vr mode through osvr plugins and openvr support

[rpavlik]

Unity does support linux as both an editor and target platform.

The OSVR plugin for Unity works just fine, as well as it reasonably can given that it's a "non-native" plugin (not integrated into the core codebase like the SteamVR one) so it doesn't look quite the same as the "built-in" VR support in Unity - compare to Unreal where we have engine source access and are a native plugin (as well as a separate plugin, if desired).

I think there may be some issues related to rendermanager and OpenGL, but in any case, a basic rendering pipeline with tracking does work on Unity on Linux via OSVR. (And, at least at one point, the Vive was working via OSVR-Vive on Linux as well, so...)

@Balderick - the build instructions simply parallel the Android ones but are simpler - get the so files and managed DLL, put them in the right place, then convince Unity that they're for the right platform.

OpenVR is an SDK for the SteamVR runtime. See the readme of this repo. I do not know any other way to run apps written against this sdk than to have SteamVR installed.

[Balderick]

Thanks for clearing that up. ;-)

[ChristophHaag]

I don't think SteamVR is supposed to be used directly by anything but the OpenVR library. OpenVR is basically nothing else but a small library that provides a public API and knows how to connect to SteamVR. Whether Valve does bypass OpenVR with their internal tools, who knows.

The Archlinux VR article is quite out of date and not entirely correct. For example the 4089 was written before a linux version of SteamVR's vrcompositor existed. Now it does, but I'm not sure it's fully working yet.

AS for OSVR-Unity, you can just download the OSVR unity plugin and import it into an unity project and create a linux build of your project. You can also compile the osvr unity plugin on linux with a bit of trickery with microsoft's .net build tools for linux. The problem is osvr-unity-rendering. In the OSVR unity plugin that you can download there is a windows version of this library included. You can build this library on linux too, it's a cross platform CMake project, but on PC platforms it only works with Direct3D, not OpenGL. I believe this issue is still valid: OSVR/OSVR-Unity-Rendering#5

That means your linux builds will have head tracking and display on a split screen, but without the osvr-rendermanager integration that the osvr-unity-rendering provides, you get no distortion correction. On the OSVR HDK2 headset, as with probably all HMDs, that makes it completely unusable. All of the osvr-unity plugin and osvr-unity-rendering library is open source, so theoretically someone from the community could fix it up, but it would need to be someone who is good with Unity and OpenGL...

[Cheeseness]

I don't think SteamVR is supposed to be used directly by anything but the OpenVR library. OpenVR is basically nothing else but a small library that provides a public API and knows how to connect to SteamVR.

This is my understanding as well. When I mentioned Unity using SteamVR for their "native VR" support on Windows, I was meaning via the OpenVR API. Apologies for any confusion.

For example the 4089 was written before a linux version of SteamVR's vrcompositor existed. Now it does, but I'm not sure it's fully working yet.

FWIW, I didn't have any luck when I tried.

[Conzar]

Also, I have not been able to get any of the Unity Games posted on itch.io working under GNU/Linux. Since the unity osvr plugin is from 2015, I think there is some incompatibility with the later versions of the OSVR Server under GNU/Linux. The dev of those games also said he was unable to get his games working on his system under GNU/Linux.

[EndeavourAccuracy]

For those of you who didn't read/see it yet,

https://twitter.com/Plagman2/status/786032888156295168
http://phoronix.com/scan.php?page=news_item&px=Steam-Dev-VR-Linux-Demo
https://www.gamingonlinux.com/articles/looks-like-vr-support-for-linux-will-be-shown-off-at-steamdevdays-this-week-about-time.8312
http://www.vronlinux.com/articles/valve-will-show-linux-vive-demo-at-steam-dev-days.29

[echuber2]

https://twitter.com/thibaultmol/status/786214172409278464

[Conzar]

@echuber2 not cool nor funny.

[Cheeseness]

Here's something that might be relevant to those offering to help.

It sounds like Valve are hunting for people with Mesa expertise to help get drivers VR ready.

[ChristophHaag]

So

/home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrcompositor: symbol lookup error: /home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrcompositor: undefined symbol: VRCompositorSystemInternal

turned out to be my fault. That happens when you try to use the OpenVR 1.0.2 libraries with current SteamVR instead of OpenVR 1.0.3.

the hellovr opengl example doesn't work at all anymore though. It segfaults with

#0  0x00007f02a5345b44 in CVRCompositorSharedTextures::UpdateTextureSet(CVRCompositorSharedTextures::Params const*, VRCompositorState_TextureSet_t*) ()
   from /home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrclient.so
#1  0x00007f02a53431a3 in CVRCompositorClient::Submit(vr::EVREye, vr::Texture_t const*, vr::VRTextureBounds_t const*, vr::EVRSubmitFlags) ()
   from /home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrclient.so
#2  0x000055ec940879b3 in CMainApplication::RenderFrame (this=0x55ec95d8ec20) at /home/chris/build/openvr-github/samples/hellovr_opengl/hellovr_opengl_main.cpp:695
        leftEyeTexture = {handle = 0x3, eType = vr::API_OpenGL, eColorSpace = vr::ColorSpace_Gamma}
        rightEyeTexture = {handle = 0x0, eType = vr::API_DirectX, eColorSpace = vr::ColorSpace_Auto}
#3  0x000055ec9408784b in CMainApplication::RunMainLoop (this=0x55ec95d8ec20) at /home/chris/build/openvr-github/samples/hellovr_opengl/hellovr_opengl_main.cpp:648
        bQuit = false
#4  0x000055ec9408d22f in main (argc=1, argv=0x7fffbe0f6998) at /home/chris/build/openvr-github/samples/hellovr_opengl/hellovr_opengl_main.cpp:1921
        pMainApplication = 0x55ec95d8ec20

If the main thread is halted on the segfault with gdb, the compositor window runs with Vulkan and shows a pink background and a small square in the top left that changes color until it eventually crashes with Fatal : VkResult is "ERROR_OUT_OF_DEVICE_MEMORY" in renderer/vulkanrenderer.cpp at line 603.

Questions that maybe people who attended the dev days talks know the answer to:

Is SteamVR still going to work with OpenGL applications or only with Vulkan applications? At least the Dota 2 demo Valve showed could have been running on Vulkan.
In other news, Dota 2 finally runs without GPU trouble on the radv driver on my RX 480: https://www.youtube.com/watch?v=l9rlDdN7twU so I have high hopes to see the VR spectator DLC run on it soon.
And the obvious question: Will we see at least beta releases of this soon?

Also sorry to Valve for my overly fatalistic comments here, but without any public information except "we're working on it" this was really beginning to sound like the most plausible thing to happen. I'm very glad to be wrong.

[DataBeaver]

I reproduced that same error with my own game (in development) and decided to apply some further debugging tools on that. First stop: valgrind.

==13948== Use of uninitialised value of size 8
==13948==    at 0xD297B44: CVRCompositorSharedTextures::UpdateTextureSet(CVRCompositorSharedTextures::Params const*, VRCompositorState_TextureSet_t*) (in /home/tdb/.steam/SteamApps/common/SteamVR/bin/linux64/vrclient.so)
==13948==    by 0xD2951A2: CVRCompositorClient::Submit(vr::EVREye, vr::Texture_t const*, vr::VRTextureBounds_t const*, vr::EVRSubmitFlags) (in /home/tdb/.steam/SteamApps/common/SteamVR/bin/linux64/vrclient.so)
==13948==    by 0x4E742D3: Msp::VR::OpenVRCombiner::render(Msp::GL::Texture2D const&, Msp::GL::Texture2D const&) const (openvrcombiner.cpp:45)
==13948==    by 0x4E6D9FC: Msp::VR::StereoView::render() const (stereoview.cpp:112)
==13948==  Uninitialised value was created by a stack allocation
==13948==    at 0xD295000: CVRCompositorClient::Submit(vr::EVREye, vr::Texture_t const*, vr::VRTextureBounds_t const*, vr::EVRSubmitFlags) (in /home/tdb/.steam/SteamApps/common/SteamVR/bin/linux64/vrclient.so)
==13948== 
==13948== Invalid write of size 8
==13948==    at 0xD297B44: CVRCompositorSharedTextures::UpdateTextureSet(CVRCompositorSharedTextures::Params const*, VRCompositorState_TextureSet_t*) (in /home/tdb/.steam/SteamApps/common/SteamVR/bin/linux64/vrclient.so)
==13948==    by 0xD2951A2: CVRCompositorClient::Submit(vr::EVREye, vr::Texture_t const*, vr::VRTextureBounds_t const*, vr::EVRSubmitFlags) (in /home/tdb/.steam/SteamApps/common/SteamVR/bin/linux64/vrclient.so)
==13948==    by 0x4E742D3: Msp::VR::OpenVRCombiner::render(Msp::GL::Texture2D const&, Msp::GL::Texture2D const&) const (openvrcombiner.cpp:45)
==13948==    by 0x4E6D9FC: Msp::VR::StereoView::render() const (stereoview.cpp:112)
==13948==  Address 0x1026399938 is not stack'd, malloc'd or (recently) free'd

Disassembly reveals the offending address to contain the instruction:

a0b44:   4b 89 04 e6             mov    %rax,(%r14,%r12,8)

Attaching gdb to valgrind with shadow registers enabled shows us the relevant register values (the s1 registers have a 1 bit where the main register has an uninitialized bit):

r12            0x4e73367        82260839
r14            0xffefffe00      68702699008
r12s1          0xffffffff       4294967295
r14s1          0x0      0

So r12 is suspect. Sure enough, calculating 0xffefffe00+0x4e73367*8 gives us 0x1026399938, the invalid memory address the instruction tried to write to. Tracing back the disassembly reveals where the uninitialized value comes from:

000000000009e000 <CVRCompositorClient::Submit(vr::EVREye, vr::Texture_t const*, vr::VRTextureBounds_t const*, vr::EVRSubmitFlags)>:
9e123:   4c 8d 75 80             lea    -0x80(%rbp),%r14
9e18d:   4c 89 f2                mov    %r14,%rdx

00000000000a08e0 <CVRCompositorSharedTextures::UpdateTextureSet(CVRCompositorSharedTextures::Params const*, VRCompositorState_TextureSet_t*)>:
a08fa:   48 89 95 60 ff ff ff    mov    %rdx,-0xa0(%rbp)
a0b30:   4c 8b b5 60 ff ff ff    mov    -0xa0(%rbp),%r14
a0b3d:   45 8b 66 18             mov    0x18(%r14),%r12d

So it should reside in -0x68(%rbp) in the context of CVRCompositorClient::Submit. The third parameter is passed in the rdx register, so the address -0x80(%rbp) should contain a VRCompositorState_TextureSet_t object (there's a hidden first parameter containing the this pointer for the CVRCompositorSharedTextures object). Unfortunately its definition is private so I don't know exactly what's in it. It appears to be 32 bytes long since -0x60(%rbp) is used as an address of the CVRCompositorSharedTextures::Params object. It also appears to be a struct since there's no constructor call to be seen, and also the naming convention seems to be to append _t to struct names.

I can deduce that the struct contains an array of eye textures in the beginning and the 4-byte value at offset 0x18 is an index to this array. Right after the failing UpdateTextureSet call the Submit function loads a pointer and checks its value. If it is null, the value 0x66 is returned. In this context it would correspond to the error VRCompositorError_InvalidTexture.

9e1be:   8b 45 98                mov    -0x68(%rbp),%eax
9e1c1:   ba 66 00 00 00          mov    $0x66,%edx
9e1c6:   48 83 7c c5 80 00       cmpq   $0x0,-0x80(%rbp,%rax,8)
9e1cc:   0f 84 59 fe ff ff       je     9e02b <CVRCompositorClient::Submit(vr::EVREye, vr::Texture_t const*, vr::VRTextureBounds_t const*, vr::EVRSubmitFlags)+0x2b>

9e02b:   48 81 c4 a8 00 00 00    add    $0xa8,%rsp
9e032:   89 d0                   mov    %edx,%eax
(some registers are popped)
9e03e:   c3                      retq

Then I had an idea. The Submit function is called from my code, so its stack resides below my function's stack. If I write a function that allocates some stack memory, fills it and returns, I can control what's in uninitialized portions of Submit's stack. So I did, choosing to fill the memory with zeroes. This was enough to make the program not crash, but unfortunately there was no improvement in functionality. The compositor still displays the pink screen with the color-changing square in the upper left corner, it still starts giving ERROR_OUT_OF_DEVICE_MEMORY after a while, and the headset still isn't tracking.

Maybe it wants both eye textures to be submitted? I found out which element of my array coincided with the index in VRCompositorState_TextureSet_t and initialized that location with 0 for the left eye and 1 for the right eye. Alas, the compositor window is still quite pink.

I don't have any other ideas, so I guess I'll just continue using Windows as my testing platform for now.

I don't know if this will be useful for Valve (I would hope they'd have found and fixed this bug themselves) or anyone else, but hopefully it'll at least be an interesting read for someone.

[ChristophHaag]

Still no news? :/

In the video from the Steam Dev Days we heard that they are working on "Vulkan-Next" with VR features.

Is it reasonable to assume that the demo was actually running on a "Work in Progress" driver with these VR features that will be found in the next major Vulkan Version and that we have to wait until this one gets released for a public release of SteamVR on Linux?

[Snowman3456]

@ChristophHaag I think that's the idea - another waiting game.

[EndeavourAccuracy]

While we're waiting for SteamVR... Vrui allows Linux users to walk around in Quake III Arena maps:
http://www.vronlinux.com/articles/quake-iii-arena-maps-in-vr-under-linux-with-vive-vrui.38
If you have a Vive but no Windows, it's one way to get your dose of VR. 😃

[kkriehl]

There has been some activity in the last month to adapt the UE4 plugin for OpenVR to Linux. Might be available soon.

[EndeavourAccuracy]

SteamVR for Linux is in beta!
https://twitter.com/VRonLinux/status/834203834293616640 😆

Repo here: https://github.com/ValveSoftware/SteamVR-for-Linux

[JoeLudwig]

Please show the SteamVR for Linux repo some love: https://github.com/ValveSoftware/SteamVR-for-Linux

That's the right place for specific Linux issues to live now.