Hi there,
I'm the author of the Unity SpaceNavigator Driver project
Github https://github.com/PatHightree/SpaceNavigator
AssetStore https://assetstore.unity.com/packages/t ... river-9774
We're working on a new implementation which uses Unity's new Input System.
This input system is based on HID and we're running into the device specific differences (no surprise there).
Is there a resource where we can find the actual details of the different hardware variants ?
We found this list, but some of it turned out to be incorrect https://github.com/openantz/antz/wiki/3 ... evice-list
The data we need is :
- Per device
- ProductID
- Per axis/button
- Which reportID
- Offset
- Size
Thanks in advance,
Patrick
P.S.
If you're wondering why I'm moving this project towards HID instead of some communication method which is closer to 3dconnexion's sdk,
this thread explains the motivation behind it https://github.com/PatHightree/SpaceNavigator/issues/35
Device descriptions for use with HID
Moderator: Moderators
Re: Device descriptions for use with HID
Hi Patrick,
You make some legitimate points in that thread.
We don't limit distribution of the part of the SDK that is linked into programs. It doesn't actually do much except load the software shipped with the driver. This gives us a place to independently extend/fix the software. If the software isn't installed on the machine, the SDK lib is dormant.
Unity might limit outside software if they ship it.
Cross platform development is not so easy. We are currently taking the approach to have an SDK that most closely matches the expected development environment of the platform, as opposed to one API that we force on every platform. It's a toss up. Generally event handling is at a low, platform-dependent level, using platform-specific code.
The HID descriptors are public, because you can read them from the devices. But you need the hardware in hand to read them.
I could dump the information from the currently supported devices for you. I also have a certain number of older devices laying around.
Which devices do you not have?
Obviously, new devices coming out in the future won't work without modification. That's the main benefit to using our SDK.
OTOH, the whole idea of the HID descriptor is to read the descriptor and use the data it contains at runtime (our drivers do that, even though I do have the hardware in hand). This insulates you from these future changes, as long as our descriptor is correct. AFAIK, all our descriptors have been correct, except for the SpaceTraveler, which has been out of production for many years. I can send you some code that picks the HID descriptor apart.
You make some legitimate points in that thread.
We don't limit distribution of the part of the SDK that is linked into programs. It doesn't actually do much except load the software shipped with the driver. This gives us a place to independently extend/fix the software. If the software isn't installed on the machine, the SDK lib is dormant.
Unity might limit outside software if they ship it.
Cross platform development is not so easy. We are currently taking the approach to have an SDK that most closely matches the expected development environment of the platform, as opposed to one API that we force on every platform. It's a toss up. Generally event handling is at a low, platform-dependent level, using platform-specific code.
The HID descriptors are public, because you can read them from the devices. But you need the hardware in hand to read them.
I could dump the information from the currently supported devices for you. I also have a certain number of older devices laying around.
Which devices do you not have?
Obviously, new devices coming out in the future won't work without modification. That's the main benefit to using our SDK.
OTOH, the whole idea of the HID descriptor is to read the descriptor and use the data it contains at runtime (our drivers do that, even though I do have the hardware in hand). This insulates you from these future changes, as long as our descriptor is correct. AFAIK, all our descriptors have been correct, except for the SpaceTraveler, which has been out of production for many years. I can send you some code that picks the HID descriptor apart.
-
- Posts: 4
- Joined: Wed Jun 30, 2021 3:00 pm
Re: Device descriptions for use with HID
We're making an inventory of tested devices over here (it's a start)
https://github.com/PatHightree/SpaceNav ... ifferences
Analysing the HID and using the data accordingly is a really good idea.
I would definitely appreciate looking at a sample implementation of that! (preferably C# if you have it)
If that works out, we're still left with the question of testing on hardware we don't have access to.
Could we ask you for help with that ?
https://github.com/PatHightree/SpaceNav ... ifferences
Analysing the HID and using the data accordingly is a really good idea.
I would definitely appreciate looking at a sample implementation of that! (preferably C# if you have it)
If that works out, we're still left with the question of testing on hardware we don't have access to.
Could we ask you for help with that ?
Re: Device descriptions for use with HID
I think you are going to have problems with the wireless devices. There is no standard way of dealing with them.
Bluetooth is fine. These nano receivers are all customized.
I hide all that mess from you behind the APIs.
We did a Unity plugin using our latest APIs. Maybe we never released it. Still, it was only in the editor, not Play mode.
I'm not sure how much testing it got.
I'll PM some HID code to you.
Bluetooth is fine. These nano receivers are all customized.
I hide all that mess from you behind the APIs.
We did a Unity plugin using our latest APIs. Maybe we never released it. Still, it was only in the editor, not Play mode.
I'm not sure how much testing it got.
I'll PM some HID code to you.
-
- Posts: 4
- Joined: Wed Jun 30, 2021 3:00 pm
Re: Device descriptions for use with HID
Indeed, we've noticed that wireless devices are acting differently from their wired siblings.
Does the technique of interpreting the device descriptors work for them ? Or did you mean that they are extra complicated in that way as well ?
I'd love to have a look at that driver
Runtime support in my driver was a static class which exposed the trans/rot data (now the Unity InputSystem is doing that data sharing bit).
The real trouble is the build and testing side, it really increases your testing surface with a platform permutation.
Thanks a bundle for the HID code !
We're digging into unity's input system, there's a layout builder in there which should fit our needs. But it's a very niche and complicated beast.
Does the technique of interpreting the device descriptors work for them ? Or did you mean that they are extra complicated in that way as well ?
I'd love to have a look at that driver
Runtime support in my driver was a static class which exposed the trans/rot data (now the Unity InputSystem is doing that data sharing bit).
The real trouble is the build and testing side, it really increases your testing surface with a platform permutation.
Thanks a bundle for the HID code !
We're digging into unity's input system, there's a layout builder in there which should fit our needs. But it's a very niche and complicated beast.
Re: Device descriptions for use with HID
Did that editor plugin ever get released?
jwick wrote: ↑Wed Aug 25, 2021 6:01 am I think you are going to have problems with the wireless devices. There is no standard way of dealing with them.
Bluetooth is fine. These nano receivers are all customized.
I hide all that mess from you behind the APIs.
We did a Unity plugin using our latest APIs. Maybe we never released it. Still, it was only in the editor, not Play mode.
I'm not sure how much testing it got.
I'll PM some HID code to you.