Skip to main content
Ethereal
Up and Coming
September 26, 2013

two programs reading sensor

I apologize if this has been asked before. I tried the search function and couldn't find any threads about it.

I'm wondering if it's at all possible to have two programs running at the same time that are both reading the orientation of the rift. If I run two programs that use the rift I see that one cannot read the sensor. Is there any way to have two programs read the orientation at the same time? If not, will there ever be?

The reason I'm asking is that I want to write a program that reads the orientation in the background while the user is playing a game.

    7 replies

    jherico
    Inspiring
    September 26, 2013
    It's not supported because the SDK opens up the Rift device in exclusive mode. I've actually tried it on Linux and it works alright, but on Windows, a second application cannot open up the Rift.

    One possible approach to that would be to create a Rift server app that talks to the hardware and allows other applications to query the orientation on an as-needed basis.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    EtherealAuthor
    Up and Coming
    September 26, 2013
    Thanks for the response jherico. The server app is a good idea, but I want this program to run alongside any rift-enabled application (not just ones that I write). So rebuilding both applications that use the sensor is not an option.

    I wonder if there is a way to modify the SDK so that it doesn't open the device up in exclusive mode (I haven't looked the SDK source yet). If it is possible, I'd have to rebuild the Unity plugin DLLs too which we don't have the source for.
    amartin
    Participant
    October 7, 2013
    For a general solution the SDK really needs to support this. I have a tool I'm working on that will need to share the oculus sensor between multiple applications. From a quick look it appears to be possible to modify the SDK to make it share but that would only apply to anythig built with that version. I wonder if the devs will accept a patch containing the modifications to allow this. I've got some more basic groundwork to do for now but I'm getting really close to needing this or my entire project won't work for what I wanted it for.
    jherico
    Inspiring
    October 8, 2013
    Hmmm.... on Linux it opens up in non-exclusive mode automatically. On my Windows 8 machine, opening the HID device in non-exclusive mode seems to work fine, but I can't be certain that the two instance of my test app are each receiving all of the messages. The OVR devs may have a reason to open it up in exclusive mode but it's not immediately apparent to me. It might be a Windows version specific issue.
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    amartin
    Participant
    October 8, 2013
    That exclusive flag seems to be on opening a file I wonder if it's something todo with windows handling shared file access worse than linux does.
    geekmaster
    Up and Coming
    October 8, 2013
    "amartin" wrote:
    For a general solution the SDK really needs to support this. ... I'm getting really close to needing this or my entire project won't work for what I wanted it for.

    It may not be possible to implement such a general solution that works reliably on all popular versions of Windows, to control the mode with which you can open a particular HID device (such as the Rift Tracker DK). The need you propose cannot be satisfied if the OS prevents it in a reliable manner...

    Your approaching "need" may be a risky system dependency that you need to design around, to avoid potential support nightmares for clients using different versions of Windows.
    :(

    According to Alan Ott (author or signal11 hidapi):
    "
    A similar situation was posted in a VRPN forum as well:
    "
    This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
    amartin
    Participant
    October 9, 2013
    "geekmaster" wrote:

    Your approaching "need" may be a risky system dependency that you need to design around, to avoid potential support nightmares for clients using different versions of Windows.
    :(


    My application is already restricted in what versions of windows it can run on due to using an API that was introduced in vista. Since the only way to get the information I need for this to work in xp is extremely slow and hackey I currently have no plans to support it. I'm neck deep in risky system dependency.

    I can display my IDE in an oculus friendly mode and allow control. Without this change I cannot then smoothly run up an Oculus app without first giving up my sensor or if I run the app up first then I cannot get the sensor at all. There needs to be some solution for this otherwise the development flow for working with the Oculus is always going to suck. I want to fix this and it looks like I can but only for my own applications currently.

    It will be possible to make this work on all versions of windows but it may not be simple to do. While the oculus is a display at it's core it is an input device. I can share my mouse and keyboard between apps I'm fairly sure I can share others too but I just realised I have not tried. The Oculus needs to be that smooth. It doesn't take much irritation to get people to put something into the too hard basket.
    Terms & ConditionsAccessibility statement