HID values reported by IO Kit are out of range when driver is installed

[Augie]

I am using OSX's IO Kit framework to get input events from the 3Dconnexion Space Navigator and Space Mouse Wireless on OSX. Everything works correctly when the 3Dconnexion software has not been installed on the system, but once the software is installed, the HID axis events start returning values that are outside the range of values reported by the HID descriptor.

For example, the X axis on the device reports the following information:

Min Value = -350
Max Value = 350
Bit Size = 16
Unsigned Max = 65536

Without the driver installed, the X axis reports values in the range of -350 to + 350. Everything works correctly.

With the driver installed, the X axis reports values in the range of somewhere around -626 to +626. (It can probably go higher than that but the value it returns at the extents is not consistent and as I wiggle it around I can get it to give me different values.)

With the driver installed, the HID min/max information is no longer valid making it impossible for me to normalize this value for use in my application.

I should state that I am aware of the 3Dconnexion SDK, but want to use direct HID communication to read values from this device.

[ngomes]

Hi Augie,

See if you can use the "3Dconnexion" preference pane to set the "speed" for your program. If you change the "speed" (a gain setting, effectively), it may be possible to return the data to the expected range.

Note that the modulus 350 is no a limit as such. It's just the range the devices use by default. The driver may increase the range to make the device feel more sensitive, making the experience more comfortable to users as less force is necessary to achieve the same change in view.

[Augie]

Hi,

See if you can use the "3Dconnexion" preference pane to set the "speed" for your program. If you change the "speed" (a gain setting, effectively), it may be possible to return the data to the expected range.

I will try this, but this isn't really a solution in my view because my software is intended to be used in other applications. That would mean everyone using an application made with my software would have to have a profile set up to undo the default sensitivity increase caused by having the driver installed.

Note that the modulus 350 is no a limit as such. It's just the range the devices use by default. The driver may increase the range to make the device feel more sensitive, making the experience more comfortable to users as less force is necessary to achieve the same change in view.

If that's true, there would be no possible way to normalize this device's values to a fixed range. Clamping the value to 350 would effectively reduce the range of motion on the device.

[ngomes]

I don't know what your application is but perhaps a product for industrial solutions is more appropriate than using an input device for PCs.

[Augie]

I don't know what your application is but perhaps a product for industrial solutions is more appropriate than using an input device for PCs.

I make an input system used in video games. I want to be able to treat the Space Mouse as a 6DoF joystick essentially. The only thing I'm able to do is clamp the value at 350.

[ngomes]

I make an input system used in video games. I want to be able to treat the Space Mouse as a 6DoF joystick essentially. The only thing I'm able to do is clamp the value at 350.

I think you can keep it clamp there. You will need to set the driver to not just the "speed" (effectively have a multiplier gain of 1).

If end-users chose to mess with the setting, then your program can ignore values > than modulus 350. Basically, allowing the users to get to "max" with less force or torque (but wasting part of the sensor dynamic range).

Did you get the speed change to work for you using the preference pane?

[Augie]

I think you can keep it clamp there. You will need to set the driver to not just the "speed" (effectively have a multiplier gain of 1).

If end-users chose to mess with the setting, then your program can ignore values > than modulus 350. Basically, allowing the users to get to "max" with less force or torque (but wasting part of the sensor dynamic range).

That's what I've done. I've tested it and it seems to work well enough. If the user needs to tweak it, they will have to go to the driver.

Did you get the speed change to work for you using the preference pane?

Yes, I was able to see the value change based on the speed in the preferences. At max speed, I was receiving values around 2500/350, so way outside the HID range. The default setting in the middle appears to be something like a 1.8x multiplier. Not sure where 1.0 would be, but I guess it doesn't really matter.

It would be nice if the HID information for each axis included a Resolution Multiplier (Here, section 4.3.1) that could be used to determine the actual min/max value.

[ngomes]

It would be nice if the HID information for each axis included a Resolution Multiplier (Here, section 4.3.1) that could be used to determine the actual min/max value.

Indeed but, sadly, we can't make changes to the HID descriptors without risking breaking applications already out there.

[Augie]

It would be nice if the HID information for each axis included a Resolution Multiplier (Here, section 4.3.1) that could be used to determine the actual min/max value.

Indeed but, sadly, we can't make changes to the HID descriptors without risking breaking applications already out there.

Thanks for your help!