Forum Discussion
Device messages and enumeration
Hey Rift Peeps.
I have a question about device messages and enumeration as the messaging is not occurring as I would have expected, but it is possible that my expectations are incorrect. Please keep in mind that I have my Rift dev kit plugged in and working on my machine while going through this.
In the first case I create a DeviceManager object and pass in a listener object (my own class that is derived from OVR::MessageHandler). When everything starts up, I do not receive any OVR::Message_DeviceAdded messages to tell me about my HMD and its sensor. I figured that was fine as I would only receive a message when a device is plugged in while my DeviceManager is running (haven't actually tested this yet).
So I follow the example and enumerate the devices from the DeviceManager. Interestingly, while I am within mDeviceManager->EnumerateDevices<OVR::HMDDevice>() my listener is called with OVR::Message_DeviceAdded messages for both devices. Then EnumerateDevices<>() returns and I can then continue on with creating the HMD device instance, etc.
I'm confused why I would receive the OVR::Message_DeviceAdded message during the enumeration step. Does this mean that I should actually handle all of my device creation within the listener and not do it following the enumeration at all (which is where the examples do it)? Would one, then, only do device creation immediately following an enumeration if you don't have a listener already set up?
Personally, it seems confusing to me that the enumeration would call the listener. This wouldn't allow for an ad hoc enumeration without adding some internal checks to my own code (i.e. an ignore message flag).
- Dave
I have a question about device messages and enumeration as the messaging is not occurring as I would have expected, but it is possible that my expectations are incorrect. Please keep in mind that I have my Rift dev kit plugged in and working on my machine while going through this.
In the first case I create a DeviceManager object and pass in a listener object (my own class that is derived from OVR::MessageHandler). When everything starts up, I do not receive any OVR::Message_DeviceAdded messages to tell me about my HMD and its sensor. I figured that was fine as I would only receive a message when a device is plugged in while my DeviceManager is running (haven't actually tested this yet).
So I follow the example and enumerate the devices from the DeviceManager. Interestingly, while I am within mDeviceManager->EnumerateDevices<OVR::HMDDevice>() my listener is called with OVR::Message_DeviceAdded messages for both devices. Then EnumerateDevices<>() returns and I can then continue on with creating the HMD device instance, etc.
I'm confused why I would receive the OVR::Message_DeviceAdded message during the enumeration step. Does this mean that I should actually handle all of my device creation within the listener and not do it following the enumeration at all (which is where the examples do it)? Would one, then, only do device creation immediately following an enumeration if you don't have a listener already set up?
Personally, it seems confusing to me that the enumeration would call the listener. This wouldn't allow for an ad hoc enumeration without adding some internal checks to my own code (i.e. an ignore message flag).
- Dave
6 Replies
- Maybe I'm missing the point of the listener, but when my application is running and I completely unplug and plug back in my Rift I am not receiving any messages through the DeviceManager listener. I would have expected to receive OVR::Message_DeviceAdded and OVR::Message_DeviceRemoved messages.
- Dave - Hey Dave,
We agree that the MessageHandler and the messages it receives are not as intuitive as you would imagine. We are looking at fleshing this out further soon, but right now consider it a work in progress. If it's a high-priority issue, let us know and we may be able to accelerate development.
What I would suggest is making sure to call EnumerateDevices<>() and use this to create the devices you need. You can probably just copy the way it's being done in the samples. You can see some sample code below which seems to be working good for me.
System::Init();
pManager = *DeviceManager::Create();
pHMD = *pManager->EnumerateDevices<HMDDevice>().CreateDevice();
if (pHMD)
{
InfoLoaded = pHMD->GetDeviceInfo(&Info);
pSensor = *pHMD->GetSensor();
}
else
{
pSensor = *pManager->EnumerateDevices<SensorDevice>().CreateDevice();
}
if (pSensor)
{
FusionResult.AttachToSensor(pSensor);
}
Hope that helps.
- Andres - Hey Andres.
No, it isn't a priority issue. I will just ignore the MessageHandler functionality for now and continue down the EnumerateDevices<>() path. So far that is working out just fine.
Thanks!
- Dave - I'm actually having trouble getting DeviceManager::Create() to work on my own project.
It works fine if I run it through the Samples' code.
What are the requirements for it to function properly?
I'm getting an access violation on AddFactory's AddToManager call.
PS. I have already called System::Init.
PPS. &SensorDeviceFactory::Instance is returning with a NULL ptr.
Solved:
Whittled the OculusRoomTiny down to almost nothing. Turns out something goes wrong if I ask the DeviceManager to Create using a static object's constructor.
Works fine otherwise.
This will crash in OVR::DeviceManager::Create():
#include "OVR.h"
OVR::DeviceManager* pManager;
class OculusManager
{
public:
OculusManager()
{
OVR::System::Init(OVR::Log::ConfigureDefaultLog(OVR::LogMask_All));
pManager = OVR::DeviceManager::Create();
};
}g_OculusObject;
int WINAPI WinMain(HINSTANCE hinst, HINSTANCE, LPSTR inArgs, int)
{
return 0;
} "cybereality" wrote:
Hey Dave,
We agree that the MessageHandler and the messages it receives are not as intuitive as you would imagine. We are looking at fleshing this out further soon, but right now consider it a work in progress. If it's a high-priority issue, let us know and we may be able to accelerate development.
Can you give us a heads-up on the plan so far? I'm working on a C# wrapper and have operated under the same assumptions than the original poster, but could not test this functionality so far because my dev kit hasn't arrived yet.
Are we to expect that that those messages arrive when the rift is physically plugged in to / out of the computer? On a related note, will references to a Sensor / HMD device be still valid when the device is plugged back in or is the software required to handle this (e.g. deleting the old devices + aquiring the new ones)?- I'm in a similar position. I'm ignoring the handler for now, but I can get the notifications the way I expect them by polling the enumeration... which is probably not a great idea performance wise.
It seems, based on the libOVR source code, that when the enumerator is created it checks to see if each device has already been created or not. If it is new, then it sends the notification, if it doesn't show up, it removes it, and if it already exists it ignores it (in terms of added/removed notifications).
If there is any additional issue I see is not being able to find the device itself based on the notifications. I know the device hasn't been created, but wouldn't it be useful to be able to get WHAT device was added/removed so the handler can remove/add it to, say, "please reconnect your Rift" notifications and what not?
Edit: I think I found a bug in the SDK based on what I described with polling. In 0.2.1, OVR_DeviceHandle.cpp, line 90: Shouldn't it be return pImpl->pDevice since "device" has not been set and thus will return NULL.
