'File' HMD driver for integration with homebrew setups #359
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is sort of similar in spirit to Monado having an 'arduino' driver (presumably for SlimeVR). However, this driver aims to allow a user to very quickly homebrew a 3DOF driver for a 'pure HMD' arrangement. In particular, I am aiming to use this driver with Moonlight/Sunshine to stream to a Google Cardboard system. Configuration is via environment variable to avoid the problem the "external" driver has (it's always present, unmarked, and needs to be ignored by end-user applications in practice).
|
Going to make this slightly more scalable to future expansion, expect commit within 24 hours |
This should still be simple enough to actually get something working, but now most edge cases are covered
|
Format's been changed to allow for tracked controllers with buttons and to generally expose more data and metadata. I should probably squash all of this into one commit, do tell me if I should do that. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This driver aims to allow a user to very quickly homebrew a 3DOF or 6DOF driver for a 'pure HMD' arrangement.
In addition, even without a custom driver per-se, it can also serve as something of a "configurable dummy driver" without being marked as a dummy driver (important for use with Monado).
In particular, I have found a use for this with Moonlight/Sunshine to stream to a "Cardboard-ish" headset, and an Android application ( https://gitlab.com/20kdc/gridlock-utopia/-/tree/master/mobile?ref_type=heads ) to stream back data to be written ( https://gitlab.com/20kdc/gridlock-utopia/-/blob/master/station3.py?ref_type=heads ).
Implementing support for the network protocol used above was considered, but ultimately I decided it wasn't likely to be even vaguely upstreamable - unexpected WinSock initialization could cause trouble for the parent application, and the protocol I used streams Android-specific data over OSC (changing the sensors was useful while trying to find a working setup).
This approach works for Monado and Neverball. (However, Sunshine limitations require the monitor to be occupied as the VR view. Therefore, for Monado, it is in practice required to use an input that 'bypasses' mouse focus, such as a gamepad. For Neverball, however, everything works.)
The driver can be activated by pointing
OPENHMD_FILEDEV_0(...)OPENHMD_FILEDEV_31at a valid file. This mechanism, while crude, is well-supported on all target operating systems and easy to work with. The file format is essentially a machine-dependent C struct, but there are no alignment issues, so it is easily written by various languages (ByteBufferin Java,structin Python,string.packin Lua).The driver stores rotations as Euler angles, in radians. This was also chosen to be easy to work with.