Repeatedly opening and closing RM will eventually fail about osvr-rendermanager

[mdutton3]

Minimum repro:
https://gist.github.com/mdutton3/403fe508459ac4a2664b42f9e6d8873f

[russell-taylor]

The HDKs are known to go AWOL after multiple DirectMode connections/disconnections. This may be taking the server down with it. Unplugging the HDK from wall, then HDMI, then USB and then plugging back in in the same order fixes things for me. Does this explain the behavior you are seeing?

This is a hardware/firmware issue that is being worked on.

[mdutton3]

@russell-taylor I have seen the HDK issue that you're describing and I think that this is separate. I'm using a custom OSVR device plugin for the HDK IMU that can handle the IMU coming and going. Even with that plugin, the RM starting and stopping will cause problems with the osvr_server. Once the problem presents, even a vanilla osvrClientInit from another app will not be able to enumerate the path tree.

[mdutton3]

From a very cursory review of createRenderManager, it doesn't look like osvrClientShutdown is called anywhere (or anywhere else in OSVR-RenderManager). It isn't called if createRenderManager early returns because it couldn't retrieve/parse config settings and it isn't called by the RenderManager destructor.

Some of this isn't terribly hard to fix (e.g. handling the early out) but I'm not sure what the life-cycle contract is when passing a context to the RM constructor. If the contract is that RM does not own the context but the context must out-survive the RM (which is what it looks like), then we have nowhere to store the context created in createRenderManager.

If you have preference on the direction to take for this issue, I can kick out a pull request.

[mdutton3]

Well apparently someone already noticed this and had a @todo in createRenderManager for it. I overlooked it.

[russell-taylor]

The RenderManager is going to need its own context. That context may be a clone of a parent context. For now, just assume it creates its own and manages destroying it, presumably in the destructor. Thanks for looking into this! Looking forward to the pull request.

[russell-taylor]

I've pulled the create/destroy of the contexts into the constructor and destructor for the RenderManager, so it should be handled now as of commit 03a422d