-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux support? #121
Comments
Sure! There will need to be a refactoring of Additionally, you'll need to implement a linux path in the |
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: 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. |
Concerning the 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. |
Hello, I have submitted an initial attempt at supporting Linux: #123 Please check the comments attached to the pull req. - there are a few things that will need to be modified before merging them. |
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:
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. |
@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. |
Hi all, |
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. |
@janoc Thank you for your reply. |
For a quick look at the status you can look at the .uplugin file of the plugin: The WhitelistPlatforms list says on which platforms the plugin will be enabled. |
@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? |
The pull request #123 has some more fixes that are probably required, but that still leaves the glew issue unresolved... |
@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. |
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.
The text was updated successfully, but these errors were encountered: