Forum Discussion
Initial XRandr support in the community SDK
The Linux version of the SDK code to locate the HMD is surprisingly primitive. It iterates across all the screens as provided by the Xinerama X11 extension, and then picks the first one that has a resolution of 1280x800 as the Rift. This can fail in two ways: if you have another screen that is running at 1280x800 or if you are running the Rift at some other resolution, you can get a false positive or a false negative respectively. The mechanism also doesn't properly identify the Rift if it's not currently an active monitor.
However, it's possible to identify the Rift via the EDID, which is accessible regardless of whether the Rift is currently enabled, as long as it's physically connected. In theory, it's also possible to interact with the XRandr extension to enable the Rift from within an application so that you can render to it.
In the community SDK (based off the official SDK), XRandr support has been added to the branch 'feature-cmake' (No, it's not a very good branch name, but the CMake code makes it much easier to add the new internal library that allows EDID parsing).
The code doesn't currently demonstrate enabling the Rift programatically from the application code, but it does positively identify the Rift regardless of it's resolution or what resolutions other monitors may be set to.
I'll merge the branch into the 'Unstable' branch as soon as I'm able to test the OSX version of the CMake functionality, and thereafter into Stable once it's reliable enough.
However, it's possible to identify the Rift via the EDID, which is accessible regardless of whether the Rift is currently enabled, as long as it's physically connected. In theory, it's also possible to interact with the XRandr extension to enable the Rift from within an application so that you can render to it.
In the community SDK (based off the official SDK), XRandr support has been added to the branch 'feature-cmake' (No, it's not a very good branch name, but the CMake code makes it much easier to add the new internal library that allows EDID parsing).
The code doesn't currently demonstrate enabling the Rift programatically from the application code, but it does positively identify the Rift regardless of it's resolution or what resolutions other monitors may be set to.
I'll merge the branch into the 'Unstable' branch as soon as I'm able to test the OSX version of the CMake functionality, and thereafter into Stable once it's reliable enough.
2 Replies
- this Identification is indeed a bit primitive.
Whats the deal with this Comunity SDK? "semidark" wrote:
Whats the deal with this Comunity SDK?
I got tired or waiting for a linux release, so i created a version of the SDK that did have it and pushed it to Github. A week later OVR released their Linux support, but I'm continuing to maintain the Github site as a repository for community added fixes and features. My current project is Java, Python and C bindings.
