3Dconnexion SpaceMouse Pro treated as "unknown device" #45243

Closed
opened 2015-06-30 03:22:49 +02:00 by Galen O'Hanlon · 17 comments

System Information
Mac OS 10.10.3.

Blender Version
Broken: 2.74

Short description of error

SpaceMouse Pro device is not detected, and is treated as "ndof: unknown device".

Exact steps for others to reproduce the error

Launch Blender via the OS X app, or from command line (I used the command line to see the log statements, e.g. "ndof: unknown device").

% ./blender
Read new prefs: /Users/gohanlon/Library/Application Support/Blender/2.74/config/userpref.blend
found bundled python: /Applications/blender.app/Contents/MacOS/../Resources/2.74/python
ndof: device added
ndof: unknown device 0000:c62b

Blender launches successfully and the "joystick" part of the 3 device functions as expected. However, no buttons are mapped. I am able to manually map some of the buttons on the device, but most of them are unusable, including the very important "ESC", "SHIFT", "CTRL", and "ALT" buttons.

The expected output would of course be:

…
ndof: using SpaceMouse Pro

The following USB device identifiers are reported by OS X's System Information app:

SpaceMouse Pro:

  Product ID:	0xc62b
  Vendor ID:	0x046d  (Logitech Inc.)

Inspecting Blender code, I see that Blender is checking for the correct vendor and product IDs, so something seems to be wrong with the code that fetches the IDs.

I attempted to add debug code to puts the vendor_id that Blender read from the device, but so far I don't haven't succeeded at building Blender on my local machine.

**System Information** Mac OS 10.10.3. **Blender Version** Broken: 2.74 **Short description of error** SpaceMouse Pro device is not detected, and is treated as "ndof: unknown device". **Exact steps for others to reproduce the error** Launch Blender via the OS X app, or from command line (I used the command line to see the log statements, e.g. "ndof: unknown device"). ``` % ./blender Read new prefs: /Users/gohanlon/Library/Application Support/Blender/2.74/config/userpref.blend found bundled python: /Applications/blender.app/Contents/MacOS/../Resources/2.74/python ndof: device added ndof: unknown device 0000:c62b ``` Blender launches successfully and the "joystick" part of the 3 device functions as expected. However, no buttons are mapped. I am able to manually map some of the buttons on the device, but most of them are unusable, including the very important "ESC", "SHIFT", "CTRL", and "ALT" buttons. The expected output would of course be: ``` … ndof: using SpaceMouse Pro ``` The following USB device identifiers are reported by OS X's System Information app: ``` SpaceMouse Pro: Product ID: 0xc62b Vendor ID: 0x046d (Logitech Inc.) ``` Inspecting Blender code, I see that Blender is checking for the correct vendor and product IDs, so something seems to be wrong with the code that fetches the IDs. I attempted to add debug code to `puts` the `vendor_id` that Blender read from the device, but so far I don't haven't succeeded at building Blender on my local machine.
Author

Changed status to: 'Open'

Changed status to: 'Open'
Author

Added subscriber: @gohanlon

Added subscriber: @gohanlon

Added subscriber: @ideasman42

Added subscriber: @ideasman42

Note that this device is supported, its just that somehow the vendor_id is zero.

OSX devs can check NDOF_DeviceAdded for why this would be.

Note that this device is supported, its just that somehow the `vendor_id` is zero. OSX devs can check `NDOF_DeviceAdded` for why this would be.

Added subscribers: @MartijnBerger, @Sergey

Added subscribers: @MartijnBerger, @Sergey

We've got OSX here in the studio. So either me or @MartijnBerger will look into it.

We've got OSX here in the studio. So either me or @MartijnBerger will look into it.

Developer note:

Can't really do definitive test here, NDof SDK seems to be conflicting with the El Capitan we've installed here for some other development. But the thing is, vendor and product IDs are coming almost directly from the Connexion SDK and then being checked right after that. So it almost seems like SDK itself is returning garbage value. Here's some snippet of code which is relevant to this:

https://developer.blender.org/diffusion/B/browse/master/intern/ghost/intern/GHOST_NDOFManagerCocoa.mm;5e9b43cc616922d3dca8567e64a568e8a1fc9012$55

@gohanlon, it'll be really cool if you manage to build blender and print value returned by the SDK. If it's wrong then don't think we can fix the issue.

Developer note: Can't really do definitive test here, NDof SDK seems to be conflicting with the El Capitan we've installed here for some other development. But the thing is, vendor and product IDs are coming almost directly from the Connexion SDK and then being checked right after that. So it almost seems like SDK itself is returning garbage value. Here's some snippet of code which is relevant to this: https://developer.blender.org/diffusion/B/browse/master/intern/ghost/intern/GHOST_NDOFManagerCocoa.mm;5e9b43cc616922d3dca8567e64a568e8a1fc9012$55 @gohanlon, it'll be really cool if you manage to build blender and print value returned by the SDK. If it's wrong then don't think we can fix the issue.
Author

@Sergey I'm working on getting the build working as we speak. I already fixed some compilation errors and now I'm working through a bunch of linker errors (which look mostly similar to each other). I hope to have the build working by later tonight. I'll then log the actual result from GHOST_NDOFManager3Dconnexion_ConnexionControl and update this issue ASAP.

BTW: I fixed a bunch of "missing type" compilation errors by applying changes similar to those in the following FreeCAD commit:

5ced7e5cbe

(Like all other Mac-based developers I know, I do generally install tools and libs via Homebrew.)

@Sergey I'm working on getting the build working as we speak. I already fixed some compilation errors and now I'm working through a bunch of linker errors (which look mostly similar to each other). I hope to have the build working by later tonight. I'll then log the actual `result` from `GHOST_NDOFManager3Dconnexion_ConnexionControl` and update this issue ASAP. BTW: I fixed a bunch of "missing type" compilation errors by applying changes similar to those in the following FreeCAD commit: https://github.com/ianrrees/FreeCAD_tinkering/commit/5ced7e5cbe3fa30c4a39f55b3a90f4b39d2ab8ca (Like all other Mac-based developers I know, I do generally install tools and libs via Homebrew.)
Author

Added subscriber: @jensverwiebe

Added subscriber: @jensverwiebe
Author

@Sergey I got a working build on OS X (thanks to some help from @jensverwiebe via IRC — scons worked great).

Unless you have any other ideas, I think I've taken this as far as I can for the moment — I'm blocked waiting for 3Dconnexion to give me access to their SDK and documentation.

As requested, I confirmed that GHOST_NDOFManager3Dconnexion_ConnexionControl is not returning the expected result:

…
ndof: device added
result: c62b
vendorID: 0
productID: c62b

(See the end of this comment for the location of the log statements that give the above output.)

If I hardcode vendorID = 0x046D, my device is "recognized" and all buttons work as expected:

…
ndof: using SpaceMouse Pro
ndof: 27 buttons -> hex:7C0F137

Here are the changes showing the log statements I added, and where I hardcoded the vendorID:

diff --git a/intern/ghost/intern/GHOST_NDOFManagerCocoa.mm b/intern/ghost/intern/GHOST_NDOFManagerCocoa.mm
index 6eedaaf..12b9cb3 100644
--- a/intern/ghost/intern/GHOST_NDOFManagerCocoa.mm
+++ b/intern/ghost/intern/GHOST_NDOFManagerCocoa.mm
@@ -53,9 +53,17 @@ static void NDOF_DeviceAdded(io_connect_t connection)
        // determine exactly which device is plugged in
        SInt32 result = 0;
        GHOST_NDOFManager3Dconnexion_ConnexionControl(kConnexionCtlGetDeviceID, 0, &result);
+
+printf("result: %x\n", result);
+
        unsigned short vendorID = result >> 16;
        unsigned short productID = result & 0xffff;
 
+printf("vendorID: %x\n", vendorID);
+printf("productID: %x\n", productID);
+
+vendorID = 0x046D;
+
        ndof_manager->setDevice(vendorID, productID);
 }
@Sergey I got a working build on OS X (thanks to some help from @jensverwiebe via IRC — scons worked great). Unless you have any other ideas, I think I've taken this as far as I can for the moment — I'm blocked waiting for 3Dconnexion to give me access to their SDK and documentation. As requested, I confirmed that `GHOST_NDOFManager3Dconnexion_ConnexionControl` is not returning the expected result: ``` … ndof: device added result: c62b vendorID: 0 productID: c62b ``` (See the end of this comment for the location of the log statements that give the above output.) If I hardcode `vendorID = 0x046D`, my device is "recognized" and all buttons work as expected: ``` … ndof: using SpaceMouse Pro ndof: 27 buttons -> hex:7C0F137 ``` Here are the changes showing the log statements I added, and where I hardcoded the `vendorID`: ``` diff --git a/intern/ghost/intern/GHOST_NDOFManagerCocoa.mm b/intern/ghost/intern/GHOST_NDOFManagerCocoa.mm index 6eedaaf..12b9cb3 100644 --- a/intern/ghost/intern/GHOST_NDOFManagerCocoa.mm +++ b/intern/ghost/intern/GHOST_NDOFManagerCocoa.mm @@ -53,9 +53,17 @@ static void NDOF_DeviceAdded(io_connect_t connection) // determine exactly which device is plugged in SInt32 result = 0; GHOST_NDOFManager3Dconnexion_ConnexionControl(kConnexionCtlGetDeviceID, 0, &result); + +printf("result: %x\n", result); + unsigned short vendorID = result >> 16; unsigned short productID = result & 0xffff; +printf("vendorID: %x\n", vendorID); +printf("productID: %x\n", productID); + +vendorID = 0x046D; + ndof_manager->setDevice(vendorID, productID); } ```

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Sergey Sharybin self-assigned this 2015-07-01 11:24:08 +02:00

GHOST_NDOFManager3Dconnexion_ConnexionControl is just a C++ wrapper around ConexxionControl() function from Conexxion SDK. So to me it seems SDK itself is giving bogus value. This we can't really resolve, sorry and thanks for the report.

`GHOST_NDOFManager3Dconnexion_ConnexionControl` is just a C++ wrapper around `ConexxionControl()` function from Conexxion SDK. So to me it seems SDK itself is giving bogus value. This we can't really resolve, sorry and thanks for the report.
Author

@Sergey I agree that this looks a lot like an upstream issue, although I think it's premature to conclude so.

It's entirely possible that the SDK API changed and Blender hasn't accounted for it. Perhaps the ConnexionControl(kConnexionCtlGetDeviceID, …) has been deprecated and the code intended to be provide backwards compatibility has a bug, or given the use of enums with that function, the enum could have been reused and now represent just the Product ID but somehow the old enum name is still defined (e.g. old “.h” file being found). If this is the case, Blender could (and should) update to the current SDK and API to resolve the issue. (I've requested but don't yet have access to the 3Dconnexion developer program, so I can’t check SDK or documentation myself.)

Also, I locally built against the SDK binaries that are installed along with the normal driver, but @jensverwiebe mentioned that building against the SDK bundled with the driver may not be sufficient, and that it was advisable to obtain the SDK through the 3Dconnexion developer access program.

Although the results of my build are consistent with the behavior I'm seeing from the official release build, once I build against the SDK obtained through the developer program the issue may even go away, which could indicate a fixable problem with Blender's official build system.

Obviously, these are just potential causes, but as far as I'm aware, they haven't been investigated and eliminated. I don’t think the two unexplored causes I presented here are exhaustive, either — this issue may benefit from the attention of others who are more familiar with Blender than I am, especially considering I know next to nothing about Blender. ;-)

@Sergey I agree that this looks a lot like an upstream issue, although I think it's premature to conclude so. It's entirely possible that the SDK API changed and Blender hasn't accounted for it. Perhaps the `ConnexionControl(kConnexionCtlGetDeviceID, …)` has been deprecated and the code intended to be provide backwards compatibility has a bug, or given the use of enums with that function, the enum could have been reused and now represent just the Product ID but somehow the old enum name is still defined (e.g. old “.h” file being found). If this is the case, Blender could (and should) update to the current SDK and API to resolve the issue. (I've requested but don't yet have access to the 3Dconnexion developer program, so I can’t check SDK or documentation myself.) Also, I locally built against the SDK binaries that are installed along with the normal driver, but @jensverwiebe mentioned that building against the SDK bundled with the driver may not be sufficient, and that it was advisable to obtain the SDK through the 3Dconnexion developer access program. Although the results of my build are consistent with the behavior I'm seeing from the official release build, once I build against the SDK obtained through the developer program the issue may even go away, which could indicate a fixable problem with Blender's official build system. Obviously, these are just potential causes, but as far as I'm aware, they haven't been investigated and eliminated. I don’t think the two unexplored causes I presented here are exhaustive, either — this issue may benefit from the attention of others who are more familiar with Blender than I am, especially considering I know next to nothing about Blender. ;-)

Even if there was a change in SDK it should behave correct. It is just given fact. If something becomes deprecated it gets removed, not broken.

Is there someone else who've got same issue on OSX?

Even if there was a change in SDK it should behave correct. It is just given fact. If something becomes deprecated it gets removed, not broken. Is there someone else who've got same issue on OSX?
Author

@Sergey Both the circumstances I described were plausible explanations, even if, as I said, they weren't the most likely. (And, I'm not sure what you're intended meaning was, because deprecation is definitely not the act of removing of code.)

I've now established with reasonable certainty that this is an upstream 3Dconnexion driver issue. I confirmed this with 3Dconnexion Mac API support, and they have a fix forthcoming.

After getting access to the 3Dconnexion Developer Program, right away I found that one of 3Dconnexion's sample apps exhibited the same NULL value for the device ID that Blender is seeing, which made reporting the issue to upstream extremely straightforward — I didn't even have to create a reduced test case myself. 3Dconnexion Mac API support was very responsive.

To recap and assist anyone who may come across this thread doing their own troubleshooting:

Despite this issue being closed, this problem is confirmed to presently be affecting, at a minimum, Blender users who meet all of the following criteria:

  • Using Blender on OS X
  • 3Dconnexion SpaceMouse Pro device (wired)
  • 3Dconnexion driver (3DxWare) version 10.2.2

I have no information about whether the bug was present in versions of 3DxWare previous to v10.2.2, whether other OS platforms were affected, or whether other 3Dconnexion devices are affected.

Affected users will continue to experience this problem until the next 3Dconnexion driver update after 3DxWare v10.2.2 has been shipped and is then installed by the user.

@Sergey Both the circumstances I described were plausible explanations, even if, as I said, they weren't the most likely. (And, I'm not sure what you're intended meaning was, because deprecation is definitely not the act of removing of code.) I've now established with reasonable certainty that this is an upstream 3Dconnexion driver issue. I confirmed this with 3Dconnexion Mac API support, and they have a fix forthcoming. After getting access to the 3Dconnexion Developer Program, right away I found that one of 3Dconnexion's sample apps exhibited the same `NULL` value for the device ID that Blender is seeing, which made reporting the issue to upstream extremely straightforward — I didn't even have to create a reduced test case myself. 3Dconnexion Mac API support was very responsive. To recap and assist anyone who may come across this thread doing their own troubleshooting: Despite this issue being closed, this problem is confirmed to presently be affecting, at a minimum, Blender users who meet all of the following criteria: - Using Blender on OS X - 3Dconnexion SpaceMouse Pro device (wired) - 3Dconnexion driver (3DxWare) version 10.2.2 I have no information about whether the bug was present in versions of 3DxWare previous to v10.2.2, whether other OS platforms were affected, or whether other 3Dconnexion devices are affected. Affected users will continue to experience this problem until the next 3Dconnexion driver update after 3DxWare v10.2.2 has been shipped and is then installed by the user.
Author

3Dconnexion Mac API support estimates that, barring the unexpected, the next release of 3DxWare for OS X will land before or around the end of this month (end of July 2015).

3Dconnexion Mac API support estimates that, barring the unexpected, the next release of 3DxWare for OS X will land before or around the end of this month (end of July 2015).
Author

3Dconnexion has published version 10.2.3 of 3DxWare 10 for OS X, and I've confirmed that it fixes this issue.

3Dconnexion has published version 10.2.3 of 3DxWare 10 for OS X, and I've confirmed that it fixes this issue.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#45243
No description provided.