3Dconnexion SpaceMouse Pro treated as "unknown device" #45243
Labels
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
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#45243
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 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:
The following USB device identifiers are reported by OS X's System Information app:
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
thevendor_id
that Blender read from the device, but so far I don't haven't succeeded at building Blender on my local machine.Changed status to: 'Open'
Added subscriber: @gohanlon
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.Added subscribers: @MartijnBerger, @Sergey
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.
@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
fromGHOST_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.)
Added subscriber: @jensverwiebe
@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:(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:Here are the changes showing the log statements I added, and where I hardcoded the
vendorID
:Changed status from 'Open' to: 'Archived'
GHOST_NDOFManager3Dconnexion_ConnexionControl
is just a C++ wrapper aroundConexxionControl()
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.@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?
@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:
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.
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 has published version 10.2.3 of 3DxWare 10 for OS X, and I've confirmed that it fixes this issue.