Skip to main content
SiSShadowman
New Participant
April 25, 2013

Correct usage of OVR::DeviceManager::EnumerateDevices<>

Hi guys,

I'm currently writing a C# wrapper for the SDK, however my developer kit has not arrived yet, so I can't really test my code. However a friend of mine is currently testing it, and for some reason it doesn't work as expected. I'm guessing that I'm using the aforementioned enumerator incorrectly (assuming it was a .NET style enumerator which points *before* the first element).

Does the following code work as intended, e.g. enumerate all devices attached to the system? I've been browsing through the SDK's source code, however this section and implementation of EnumerateDevices<> is not heavily commencted:


auto enumerator = _manager->EnumerateDevices<OVR::SensorDevice>(true);
while(enumerator.IsAvailable())
{
	// There's a device, use it...

	if (!enumerator.Next())
		break;
}


Does IsAvailable() always report true for those cases where CreateDevice() returns non null? The documentation of the SDK says that EnumerateDevices returns an "empty" enumerator, and I'm guessing that IsAvailable() is meant to indicate wether or not it's empty, but this is just a guess on my side.

On a related note, how can I go about deep cloning a DeviceHandle? I'm asking because I would like to represent this functionality as an IEnumeration<IDeviceHandle>, however this kind of relationship is very different fromt he SDK's one, in which an enumerator is a kind of DeviceHandle, and hence moving the enumerator to the next element modifies the handle as well. I think that this would introduce subtle bugs (e.g. users calling EnumeratorDevices.ToList() would end up with a list of N identical device handles).
I'm afraid that I'm no longer in the realm of the public interface of the SDK, however I think that for the moment, it would really help the wrapper.

On another note, which licenses am I allowed to publish this wrapper under? Ideally, I would like to use a very lenient license, so it can be used in commercial and non-commercial products without any hassle. Do you have any information on that as well?

    3 replies

    kojack
    kojack
    Honored Contributor
    April 25, 2013
    It's hard for me to say definitely, since I don't have a rift for it to enumerate so I can't debug the code, but the sdk code looks like it might be wrong.

    Here's the code of IsAvailable:
    bool DeviceHandle::IsAvailable() const
    {
        // This isn't "atomically safe", but the function only returns the
        // recent state that may change.
        return pImpl ? (pImpl->Enumerated && pImpl->pLock->pManager) : false;
    }

    The current enumerated device is available if it has been enumerated and it's lock has a manager.
    Doing Next() on it will iterate through the next devices in the list, skipping any already enumerated ones.

    The problem is that I can't find anywhere that ever sets Enumerated to true. Ok, there's a place that does, but it's in EnumerateFactoryDevices(), which isn't used when you are manually enumerating individual devices. I'd guess that DeviceHandle::enumerateNext() is where Enumerated should be set to true, since that's the bit that iterates through the devices.

    Although maybe I'm just missing the intention of the code and this is correct behaviour. The comments are a bit thin.
    Author: Oculus Monitor , Auto Oculus Touch , Forum Dark Mode , Phantom Touch Remover , X-Plane Fixer Hardware: Threadripper 1950x, MSI Gaming Trio 2080TI, Asrock X399 Taich Headsets: Wrap 1200VR, DK1, DK2, CV1, Rift-S, GearVR, Go, Quest, Quest 2, Reverb G2, Quest 3
    kojack
    kojack
    Honored Contributor
    April 25, 2013
    A better way to iterate might be:
    auto enumerator = _manager->EnumerateDevices<OVR::SensorDevice>(true);
    while(enumerator.GetType() != Device_None)
    {
       // There's a device, use it...

       enumerator.Next();
    }


    If there's no device returned by EnumerateDevices, it gives you Device_None as the type. The same happens when you have iterated past the end of the device list.
    Author: Oculus Monitor , Auto Oculus Touch , Forum Dark Mode , Phantom Touch Remover , X-Plane Fixer Hardware: Threadripper 1950x, MSI Gaming Trio 2080TI, Asrock X399 Taich Headsets: Wrap 1200VR, DK1, DK2, CV1, Rift-S, GearVR, Go, Quest, Quest 2, Reverb G2, Quest 3
    SiSShadowmanAuthor
    New Participant
    April 25, 2013
    Thank you very much. I'll try this one and report back once I have confirmation.

    They should add a bit more documentation to their SDK, this is just one part where it's unclear on how it actually is supposed to behave. Granted, those parts are probably rarely used by most people, as they only need a SensorFusion to retrieve the orientation and whatnot.
    Terms & ConditionsAccessibility statement