Spacemouse support for linux

johannes_w

Hi guys!

Linux is not the hidden and nerdy OS it was a few years back. Many are switching from Mac/Windows to Linux already and since onshape has been brought into being, also CAD engineers are free of the windows chains! Which is great! But it is still a great barrier that there is no real support for 3d mice in linux. I know there is the spacenav project but as far as I understood this, there is no real compatibility between onshape and the spacenav driver (only blender).

3dconnexion stopped the linux driver support long time ago. So please take this request serious and work something out with 3dconnexion. You (the company) have a lot more weight than single users who complain about this at 3dconnexion.

One last thing, is there any documentation of how to control navigation in onshape like a 3d mouse does? In other words how does onshape get the input? Maybe there is a possibility to write some kind of android app that converts the smartphone into an air mouse using its accelerometer. I'm a spare time programmer and unfortunately, not a very good one. So I stand corrected if I'm blabbering nonsense about navigation control in onshape. I really have no idea how this usually works

TimRice

We do not have any control over which OSs 3DConnexion supports so it is up to users to continue to pressure for Linux support.

owen_sparks

If I were Onshape I might look at a partnership with with 3dconnexion. An Onshape Pro / Enterprise package that came bundled with a cad mode might be attractive to new users and give OS some influence with 3DC drivers and profiles.
Owen S.

john_mcclary

Android accelerometer 3dspace mouse...

That would be nice! Hope it would be able to push it's output into an android app on the same device. like onshape moblie, or chrome mobile. On top of 'converting' your phone into a bluetooth 3dmouse for use on a pc

johannes_w

TimRice said:

We do not have any control over which OSs 3DConnexion supports so it is up to users to continue to pressure them into supporting Linux.

I've read the other topics regarding this matter and it's always the same answer. "It's the fault of 3dc not us. They canceled the driver support."

Don't get me wrong. I love onshape and I REALLY appreciate how you revolutionized CAD! It's what many design engineers have been waiting for! But right now, the lack of interest regarding this matter dulls my opinion about your company a bit. I can assure you, there are enough linux users who do CAD but without a 3d mouse? Not very productive.

Like @owen_sparks already mentioned, onshape is really great at partnering with many cool companies and I love that. So why not do the same with 3dc?

The alternative would be to publish some kind of API to be able to connect to the navigation of onshape.

johannes_w

Thank you @john_mcclary ! I appreciate your interest!

I've found an application which is able to exactly do that. https://play.google.com/store/apps/details?id=com.sdt.pccontrol

The problem here is, that it uses mouse controls so unlike a typical 3d mouse, you won't be able to navigate while using your mouse for editing/selecting etc. So it would be cool if there was a way to address onshape navigation directly.

john_mcclary

Thanks for the link.

By the way Onshape does support 3dmouse. But it does fall into the hands of the hardware dev to interface with the OS. Onshape does not write direct hardware calls. And I doubt an up and comming CAD company will be able to convince 3dconnexion to do anything. Most users are still mac/windows. And a 3dmouse is a luxury accessory.

So little to no incentive for either company. So the only voice with power to change minds is the voice of the customer to the creator of the tool (3dconnexion)

I'm sorry but this is crappy but true

johannes_w

Thank you for this clarification. I did not know that!

So basically, Onshape does not communicate with the hardware itself in any way. All it does is offering a separate input for 6 DOF devices to be able to use mouse and 3d mouse simultaneously.

That means, that if I used a software which simulates the output of a 3dc device, Onshape will register this data as navigation. Like a desktop application that receives the input from the android device (Regarding the air mouse).

Am I right with these assumptions?

I checked the linux HID driver support and currently, only a few VERY old 6DOF controllers (pre 2000) are supported.

Is there any standard protocol for 6DOF controllers that applies in order to communicate with Onshape?

I am willing to invest some time in finding an adequate solution but for this I need information like this so that I know where to start.

johannes_w

Ok I've dug up my old joystick. A Saitek Cyborg X F.L.Y 5 .

It is natively supported by linux. I checked, if firefox registers the joystick input and it does. Using this website:

http://html5gamepad.com/

All axis and all buttons are registered correctly. Unfortunately, Onshape does not agree

Does anyone have ideas how to get this to work? It would be a cool thing in general, if Onshape supported standard gamepads. This way, one could play and test everything out before buying an expensive 3D mouse.

There would be whole new possibilities of navigation. Like the magic leap concept which has already partnered up with Onshape!

Jake_Rosenfeld

Hi All,

I don't love being the bearer of bad news, but our integration with the 3dconnexion does not go though the standard channels of interaction through built-in browser events (like the mouse does).  It is a very specific integration that involves a proprietary API between us and them.  We could consider exposing a public-facing navigation API that any user could program against (to make a custom controller), but this is not as simple as exposing an API we already have; it would require additional design and development work.  If you would like to see an API like this exposed, please create an Improvement Request using the Improvement Requests category of this forum.

johannes_w

I've already made an improvement request for the integration of html5 gamepad. I did a little research about how onshape handles the com with 3dconnexion a few days ago. I came to said results and contacted the developer of the spacenav project. He will look into it and check, if he can update his driver to the new com protocol of the 3dconnexion driver.

If I may ask, was there a specific reason that you've created a new protocol instead of using the standard protocol every desktop CAD system uses?

Also, wouldn't it be possible to feed your proprietary API with the data of the html5 gamepad API? This would unleash new possibilities as I've already explained in the improvement request.

Thanks for the explanation and your time!

Jake_Rosenfeld

@johannes_w

We try to only use W3C supported standards in our product.  While the gamepad is supported (with different levels of support) by some of the major browsers, it is not an accepted standard yet:
https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API#Specifications
We appreciate your IR, and will prioritize the work based on the the number of interested users.

As far as our connection with the spacemouse: 3dconnexion determined the spec of our integration. 3dconnexion's desire to have their devices have a uniform feel across different programs eliminates the possibility of using the html5 gamepad API as the platform for the integration. With the lack of any supported browser-level APIs for something like this (especially back in 2015) we had to make a proprietary API to connect with 3dconnexion devices.

I am not familiar with the standard protocol that spacenav uses with other CAD products, but I suspect that the difference is not what data is passed from the driver to the program, but rather how the data is passed from the driver to the program.  I could be wrong though.

It would be possible to feed gamepad input into the API we already have, but this would require work either to a) make a user-facing well-designed public interface for generic navigation input or b) implement native gamepad support within our product.  Either way, there is work required, which is the goal of our Improvement Request system.