Linux support?

[djiamnot]

Hello,
I had a look to see if there any chance to have this plugin work in Linux but it seems very Windows centric. Are there any plans to support Linux in foreseeable future? Any pointers to where to start to even attempt that?
Thanks in advance.

[JeroMiya]

Sure! There will need to be a refactoring of FOSVR::LoadOSVRClientKitModule in OSVR.cpp to work on Linux. Ideally, it would work in a way where most of the code is the same but on Linux we add '.so' to the base lib name instead of '.dll' (with some platform-specific libraries, like d3dcompiler_47.dll), and add the right platform subpath in the pathsToTry array. But if it's easier to just have each platform use its own arrays, that's fine too. The section below the array definitions though should be common among platforms - it's currently in the windows only path but doesn't have to be.

Additionally, you'll need to implement a linux path in the OSVRClientKit.build.cs file. There is currently a windows and Android build path. This is also where ideally we'd use a common list of base library names (plus some platform specific libraries) and then construct the platform specific ones.

[janoc]

Hello @JeroMiya

I can help with the Linux support, at least for the native Linux port. I have been trying to build OSVRInput that is included with the 4.13 yesterday (simply whitelisted it for Linux in addition to Win64) and there are a few things that are incorrect in the code:

E.g. code like:
OSVR_API class IOSVR ... breaks the compilation. The visibility attributes/export declarations are supposed to be after the class keyword, not before. I.e. the correct syntax is class OSVR_API IOSVR... This mistake is there about 4-5 times from what I could see.

Visual Studio will probably compile this trying to be "helpful" but clang emits a warning that these misplaced attributes are ignored. That breaks the build, because the Linux build is done with -Werror (warnings as errors). And when you disable -Werror, then the plugin will fail to load with missing symbols (something about server autostart, don't have it in front of me atm), because they haven't been exported.

I am not sure whether it makes sense to submit a pull req. for this, because you are refactoring the code and the released plugin included with Unreal Engine is an older version.

I didn't need to do anything with the paths for Linux, but then I have built OSVR myself and the path is in the CMake's cache.

[janoc]

Concerning the FOSVR::LoadOSVRClientKitModule - hmm, is that the Unreal's policy that all these libraries have to be explicitly pre-loaded "by hand"? Wouldn't it be simpler to rely on the dynamic linker to find the libraries as needed (which also makes things start up much faster), perhaps providing it the path where to search for them, if it isn't standard? The system knows what to load when you link your module with the libraries during building.

That is how I have handled this when building my own OSVR support for Unreal before - it was sufficient to put the OSVR dependencies next to the plugin DLL and they were picked up automatically (but that was an external plugin). I assume that if I have put the OSVR DLLs to the same place as the rest of the Unreal binaries (i.e. Engine/Binaries/Win64 or Engine/Binaries/ThirdParty/XXX), it would have worked as well.

I find this manual loading of the dependencies a fairly fragile practice - you link with a different version of the library and then must be careful to update the path or filename in the loader as well if the filenames are versioned (which is, IMO, a good idea to start doing - avoids DLL hell. Linux shared libraries are commonly versioned). If you don't = crash. Also it makes things complex for handling cross-platform compatibility, because each system names shared libraries differently. E.g. Linux adds "lib" prefix too, so you have libosvrClientKit.so, Windows has osvrClientKit.dll, Mac uses libosvrClientKit.dylib convention, etc.

[janoc]

Hello, I have submitted an initial attempt at supporting Linux: #123
It works to the point that I am able to load the plugin and it connects to my OSVR server and lets me move things in the scene using my Razer Hydra.

Please check the comments attached to the pull req. - there are a few things that will need to be modified before merging them.

[JeroMiya]

FYI: if you have hydras, you can add this to your server config and emulate an HMD for display purposes on Linux even if you don't have an HDK:

"aliases": { "/me/head": "/me/hands/left" }

I would also create a display config and render manager config that uses extended mode and a non-fullscreen window smaller than your dev monitor.

[janoc]

"aliases": { "/me/head": "/me/hands/left" }
Not a bad trick, should have thought about that one.

I would also create a display config and render manager config that uses extended mode and a non-fullscreen window smaller than your dev monitor.

Will have to look into that first, I have never used render manager before. We have always used OSVR only for tracking/metadata.

[janoc]

@JeroMiya I have managed to get the RenderManager to work and got the OSVR-Unreal code to build with the rendering support, however I am getting a crash about invalid OpenGL enum on opening display. See the #123 for the stack trace, I didn't want to pollute this issue with it.

If you have a clue what could be the problem, I am all ears.

[ronir121]

Hi all,
I was wondering if this code is already submitted to the official version?
I'm using UE 4.15 with the built-in OSVR-Plugin that comes with it, and when I run the game on Linux (Arm64), there's no connection to the OSVR Server (at least no prints from the server that a connection was made). The game runs and I can move it with the mouse cursor, but the headset doesn't move anything.
Is there still no support for Linux for this plugin?

[janoc]

Well, sadly there is an unaddressed issue #123 with GLEW which will likely block any upstream merge in Unreal. Unfortunately, it is not something I want to start changing myself as a 3rdparty dev, because it requires either changing to a different library or forking GLEW. The OSVR devs need to decide what they want to do here.

Judging from how long this has been here, I wouldn't hold my breath for it to be merged any time soon.

[ronir121]

@janoc Thank you for your reply.
I wonder if I'm talking about the same scenario.
Are you talking about compiling the plugin on Linux or on Windows?
Just to make sure - I compiled on Windows, packaged it via cross compiler to Linux Arm64, then just executed the file on Linux. It runs fine but with no connection to OSVR.
Is this supposed to work?

[ChristophHaag]

For a quick look at the status you can look at the .uplugin file of the plugin:
https://github.com/EpicGames/UnrealEngine/blob/4.16/Engine/Plugins/Experimental/OSVR/OSVR.uplugin
https://github.com/OSVR/OSVR-Unreal/blob/master/OSVRUnreal/Plugins/OSVR/OSVR.uplugin

The WhitelistPlatforms list says on which platforms the plugin will be enabled.

[ronir121]

@ChristophHaag So you think I might be able to just add "Linux" to the whitelist and then it will work when I run it on Linux?

[ChristophHaag]

The pull request #123 has some more fixes that are probably required, but that still leaves the glew issue unresolved...

[janoc]

@ronir121 It doesn't matter whether you crosscompile or you compile natively. However, because you are speaking about cross-compilation, I believe you have used the source that ships with Unreal. That version does not work in Linux. That has been the entire raison d'être for this bug report and my pull requests.

Unfortunately it is not possible to simply whitelist the plugin. It won't build and work as-is. The code from #123 needs to be merged first, then there are a few loose ends that the OSVR maintainers need to fix that I didn't know how to do - mainly where to put the libraries and what is their canonical way to find them on Linux (yay for the horrible Unreal build system!)

And @ChristophHaag is correct - without getting the GLEW problem fixed it would be possible to use only the tracking part anyway. The display manager part has no chance to work. It would make the engine crash on start because GLEW is attempting to use OpenGL functions that are removed in the Core profile - which is what Unreal is using.

There is now a merge conflict on #123, but that is a trivial refactoring (some code has been moved few lines down).

I have done most of the work but unless the OSVR maintainers actually fix the above, the Linux OSVR support is going to remain broken in Unreal.