Skip to content
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

Doesn't run on OSX #34

Closed
SoylentGraham opened this issue Jun 18, 2017 · 12 comments
Closed

Doesn't run on OSX #34

SoylentGraham opened this issue Jun 18, 2017 · 12 comments

Comments

@SoylentGraham
Copy link

Firstly, it bails out with Libraries not available for this platform: Darwin, as the lib is not setup.
The "32 bit" dylib from openvr, is actually a universal library, so has x86 and x64 images. (you can test this using lipo -info libopenvr_api_32.dylib), so init.py needs updating.

Secondly, you need to specify the full path for LoadLibrary on osx or it won't find the library with dlopen() (updating the PATH means nothing)

loadpath = os.path.dirname(__file__) + '/' + _openvr_lib_name
openvr = cdll.LoadLibrary(loadpath)

Working on next set of errors... :)

@cmbruns
Copy link
Owner

cmbruns commented Jun 22, 2017

Thanks for investigating this. I haven't got steamvr working on a Mac, so I cannot debug this myself at the moment.

@liffiton
Copy link

I've gotten pyopenvr to load and work perfectly (at least with a single VR tracker) on OS X with just a single change in __init__.py to make it load the libopenvr_api_32.dylib library on 64-bit Darwin. I didn't run into any of the other issues SoyletGraham mentions. Perhaps those have been fixed in more recent changes.

Regardless, if you simply copy the Darwin check:

elif platform.system() == 'Darwin':
    _openvr_lib_name = "libopenvr_api_32.dylib"

into the 64-bit "else:" clause in __init__.py, it works for me. I can open a pull request if it would be helpful.

@paulreimer
Copy link

I can confirm this worked for me also. All seems well with that 1 line change.

@ianesten
Copy link

Another report of success for the change to init.py. Please make the change to the package!

@tomgoddard
Copy link

I also confirm that adding the two lines suggested by liffiton in Nov 16, 2017 comment allows pyopenvr to work on Mac OS 10.14 (Mojave). I've attached the patch file that adds those two lines that I use with my VR app (ChimeraX) (attached as a zip file since GitHub will not accept attachments with .patch suffix).

openvr_mac.patch.zip

@tomgoddard
Copy link

Hand-controller button press events all return button id 0 instead of correctly identifying which button is pressed. This is the same problem as on Linux described in issue #35. The patch that fixed the Linux issue only applies the fix if sys.platform() == 'Linux'. Applying the same fix for Mac makes the buttons work in VR. Here is my patch of openvr/init.py that makes the buttons work on Mac and also makes in find the libopenvr_api_32.dylib on 64-bit macOS.

openvr_mac.patch.zip

Even with this patch SteamVR is not working correctly on macOS 10.14 (mojave) from a MacBook Pro laptop (2016 13 inch, Intel graphics only) (13,2) with an external GPU (AMD Radeon Vega 56 in Sonnet enclosure). The VR images display but flicker severely (5-30 frames/sec) using the ChimeraX VR molecular display application I work on, and the right eye image is not correct. It is not clear if these are problems in SteamVR on Mojave, in ChimeraX or in pyopenvr. Most likely they are bugs in SteamVR on Mojave.

@tomgoddard
Copy link

Patch in previous comment is wrong -- would break openvr on Windows. Here is the correct patch that only alters behavior on Linux and Darwin.

openvr_mac.patch.zip

@cmbruns
Copy link
Owner

cmbruns commented Feb 21, 2019

@tomgoddard @SoylentGraham @liffiton @paulreimer @ianesten
I made a slightly different patch for OSX in the latest release https://github.com/cmbruns/pyopenvr/releases/tag/1.2.1002
Can you please verify whether this works correctly on Mac?

@liffiton
Copy link

I'm afraid I'm no longer working on that project, and I don't have the equipment to test any more. Sorry.

@tomgoddard
Copy link

tomgoddard commented Feb 21, 2019 via email

@cmbruns
Copy link
Owner

cmbruns commented Feb 22, 2019

@tomgoddard Awesome! Thank you. I'm inclined then to close this issue soon.

@SoylentGraham
Copy link
Author

Yeah, I'm also no longer using this either. I just wanted to make sure I made records of stuff I found in case other people had the same problem.

@cmbruns cmbruns closed this as completed Feb 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants