Skip to main content
sbdykes
Up and Coming
March 30, 2016

1.3.0 and mouse focus

It appears to be the case that the new 1.3.0 runtime is doing something "interesting" with mouse focus/exclusivity, namely that it is somehow forcing the mouse cooperative mode to be foreground exclusive for the currently running VR app (global mouse cursor is gone until VR application loses focus).  My project is specifically and intentionally NOT setting mouse exclusivity (at least when in its own dev mode).

Is anyone else getting this behavior?

I think I can understand the general reasoning behind this (prevent the user from inadvertently clicking on something with the headset on, which might make the VR app lose focus, etc.).  However, I think this is really best left to the application itself, or at least as something you can switch off for dev purposes.  It's not the end of the world, but it's an annoyance, and I could see how changing the system mouse behavior might cause issues for some applications not expecting it.

    13 replies

    Show previous replies
    wbsk
    Up and Coming
    April 1, 2016
    @ sbdykes I'm only just getting our current games working with 1.3 as I have been moving around a lot of stuff.  But provisionally they seem to be getting mouse input via windows messages ok, and I can still click on other windows to change focus.  So I am not seeing the current behaviour you describe I think but I am still far from finished with the update and testing.  This is on a Windows7 machine.

    We haven't moved our stuff to raw mouse input yet though (but we intend to...).  So maybe that's the problem?
    jherico
    Inspiring
    April 1, 2016

    cybereality said:

    @galopin The main issue is mouse focus and how that interacts with Oculus Home and the application switching which one is currently active. I don't know all the details, but it seems difficult to guarantee that the client application has mouse focus. This may not be an insurmountable problem, but it's also not an easy thing from what I understand. The gamepad is not affected by this because defocused apps can still receive input from XInput. But I do understand the desire to support mouse controls and I can pass this feedback to the team.


    I get this, I really do.  In order to not drive people insane, our application has to capture the mouse pointer while in an HMD mode, so that people can't accidentally click off the application while manipulating the UI in the HMD.  This in turn begs the question, how do I take off the HMD and then go into the application menu to switch back to desktop mode, or how do I start using the mouse with Oculus home.  

    The answer seems pretty obvious....  any application that captures the mouse input in this manner must release the input if the HMD is taken off.  Since the Oculus API exposes this, it should be pretty easy to test for.  
    Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
    sbdykesAuthor
    Up and Coming
    April 1, 2016
    Ok, embarassing revelation time.  After debugging this deeper, it turns out *I* was the one changing the mouse exclusivity for my application.  Even more embarassingly enough, I am explicitly and purposefully invoking the above described behavior when I go into stereo rendering mode, for the very reasons I reasoned Oculus would be doing it.  Unfortunately, it had been a bit of time since I had tried any mouse-related tasks with the Oculus (an update ago), and it completely slipped my mind that I had done this.  <insert picture of me with hand over eyes>

    So, the very good news is that the Oculus runtime is completely innocent of any mouse shenanigans, and this was a big 'ol false alarm.  Mea Culpa.  I am restricting my Mountain Dew intake today as punishment.

    Of course, the points raised above by everyone about whether it should be an officially supported device are still valid, but there has been no change insofar as the Oculus side goes as to how it handles mouse input/focus.

    Now, if no one minds, I'm going to go and put my head through the wall.
    Terms & ConditionsAccessibility statement