Checking vive wand handedness within driver API

[danwillm]

We are currently running into a couple of issues trying to discover vive wand handedness.

The wands don't seem to have any handedness associated with them in Prop_ControllerRoleHint_Int32, returning TrackedControllerRole_Invalid when fetching the property.

We've seen that the wands don't have a set handedness for each controller and set it dynamically, but constantly trying to fetch their Prop_ControllerRoleHint_Int32 (even after apparently identifying handedness) consistently returns 0 (TrackedControllerRole_Invalid).

It's important to us to know what SteamVR allocated the controller handedness as, and we were wondering if there was any way to retrieve that information?

Thanks.

[Rectus]

Have you checked that you are passing the correct device index to GetInt32TrackedDeviceProperty()? It's only supposed to return 0 if the index is invalid.

Edit: Didn't see it was for the driver side. I don't think the driver API supports accessing devices from other drivers.

[danwillm]

Hey,

You're able to get tracked device properties (and actually set properties of other devices🤔) in the driver API. https://github.com/ValveSoftware/openvr/blob/master/headers/openvr_driver.h#L3263

This method works perfectly fine all other controllers who expose their handedness correctly via Prop_ControllerRoleHint_Int32, but does not seem to be the case for Vive Wands, who for some reason give TrackedControllerRole_Invalid, even after having a "role" assigned to them.

The only solution we've found to fix this problem is to actually go ahead and set the wand handedness ourselves (which we can actually do for some reason) and force each wand to be either left or right handed, which we think is an awful solution.

[JoeLudwig]

That is an awful solution and you shouldn't do that. :) You'll end up interfering with the existing handedness determination, which handles trackers in hands, other kinds of controllers mixed with wands, etc.

The property you're referring to is an input to the "which controller is in which hand" system, not the output of it. That's why it doesn't update when the roles are assigned. There are situations in which that assignment should be re-evaluated and hard-coding the hints will interfere with that.

Your best bet is to run an overlay app on the client side of the API and send the current assignments over to your driver. You can read the current assignments easily from the client with these two functions in IVRSystem:

    /** Returns the device index associated with a specific role, for example the left hand or the right hand. This function is deprecated in favor of the new IVRInput system. */
    virtual vr::TrackedDeviceIndex_t GetTrackedDeviceIndexForControllerRole( vr::ETrackedControllerRole unDeviceType ) = 0;

    /** Returns the controller type associated with a device index. This function is deprecated in favor of the new IVRInput system. */
    virtual vr::ETrackedControllerRole GetControllerRoleForTrackedDeviceIndex( vr::TrackedDeviceIndex_t unDeviceIndex ) = 0;

[danwillm]

Hi Joe,

Thanks so much for that information, we really appreciate it and wouldn't have spotted it otherwise.

The use of the overlay brings us onto another issue that we opened a few weeks ago about why VRIOBuffer was deprecated - we thought VRIOBuffer was a reasonable solution to achieve this communication between client->driver (#1543), but since we discovered that it has been deprecated we have been looking for alternatives to this type of functionality we would like to have.

It would be really beneficial to us to know why VRIOBuffer was deprecated and if there's any other solutions OpenVR provides to solve this problem, rather than other ipc methods.

Thanks again.

[JoeLudwig]

IVRIOBuffer's only use inside SteamVR was to expose IMU samples in a way that suffered from unfortunate interface versioning challenges. We're not using it internally for anything else as a result. We did end up restoring the IMU sample IO Buffer, but wouldn't encourage new external uses of it.

I encourage you to find an off-the-shelf IPC mechanism and use that instead of depending on anything inside the SteamVR API. That will have the nice side effect of continuing to work if/when you convert the overlay side to OpenXR.

[danwillm]

Awesome, thanks so much for taking the time to reply, we really appreciate it 🙂 - I'll close the other issue and link it here.