3DConnexion SpaceNavigator in Linux

By | July 23, 2010
9 Comments

3D Connexion Space Navigator

Existing SpaceNavigator Support

3DConnexion makes a nice 6DOF device reminiscent of the old SGI Spaceball – a 6DOF joystick (3 translations + 3 rotations/twists).

In Linux there are several options how to get it to work:

  • Official 3DConnexion drivers
    The Linux driver is obviously derived from the Unix drivers and requires several things that are poor design decisions – Motif (OpenMotif works), root permissions to run the daemon and modification of /etc/inittab if the driver is installed using the provided script. Moreover, the daemon tries to open an X window with configuration and will not work right without it. This is difficult on most Linux distributions due to the X access controls, requiring nasty things like xhost+ and similar. Overall, the design is a security liability. Applications need to connect to the device using specially written clients/plugins. Moreover, the driver is proprietary, with no source code, causing problems with compatibility.
  • Spacenav project – a free re-implementation/drop in replacement of the official driver. Not full-featured yet.
  • VRPN – A good choice for VR applications. I have contributed the Linux support for the SpaceNavigator using the Linux USB input framework (HID devices).
  • libndofdev – Library originally distributed to support SpaceNavigator on Windows and OSX by 3DConnexion, now maintained by Linden Labs, makers of Second Life to support SpaceNavigator in Second Life client. The library has no real Linux support yet, however I wrote a compatible drop-in replacement using the published API that allows Second Life viewers use both joysticks and SpaceNavigator on Linux (see below).

Installing SpaceNavigator without the official driver

  1. Make sure the evdev kernel module is loaded (e.g. via /etc/modprobe.preload)
  2. The SpaceNavigator device file will appear as /dev/input/event*, the correct device can be found by typing dmesgright after connecting the Navigator. Then look for a lines similar to: 
    usb 7-2.3: new low speed USB device using uhci_hcd and address 26
usb 7-2.3: configuration #1 chosen from 1 choice
input: 3Dconnexion SpaceNavigator as /class/input/input73
input,hidraw5: USB HID v1.10 Multi-Axis Controller [3Dconnexion
SpaceNavigator] on usb-0000:00:1d.1-2.3

    The important line is the one starting with input: 3Dconnexion.
    Type ls /sys/<class/input/input*>, filling in the info from this line and you will obtain:

    $ ls /sys/class/input/input73
capabilities/  device  event5/  id/  input:event5  modalias  name
phys  power/  subsystem  uevent  uniq

    The device is then connected as event5, the correct path being /dev/input/event5, in my case.

  3. Most likely regular users will not have access to the device (the default on most Linux distros). The official drivers work this around by running everything as root, which is a security problem. A better approach is either using chmod (need to be done after every reboot and every re-connection of the device) or using udev rules.

    These rules will ensure that the currently logged in user will automatically be granted access to the device. Also, a convenience symlink /dev/input/spacenavigator will be created. Note: The rules above are designed for Mageia Linux, different distros (Ubuntu, Suse, …) may need different rules.

  4. If your Linux uses HAL for device management, it is possible that your Navigator will be recognized as a mouse and the cursor on the screen will keep moving when you apply pressure on the cap. Annoying. In order to fix that, we have to tell X to ignore the device by removing the “input.x11_driver” key.
    • Create the file /etc/hal/fdi/policy/90-spacenav-nox11.fdi (right click and “Save link as …” – the file will appear empty in the browser if you only click on the link!)
    • Restart your system. The problem should be fixed.

Using the SpaceNavigator

There are not many programs able to use SpaceNavigator in Linux right now. However, adding support is fairly simple. Apart from using VRPN, which is an overkill for simple projects, it is easy to use the device directly using the input framework as HID device.

  • spacenavig.c This example is in public domain, credit is appreciated.

Note: If you have the official driver installed (or spacenav driver, not tested), you need to stop the daemon otherwise the example will not work.

Second Life support

This section is obsolete. The current version of the SecondLife viewer has the support for the SpaceNavigator and joysticks on Linux built-in. Enjoy 🙂

Second Life supports SpaceNavigator in Windows and MacOS X, together with regular joysticks. Unfortunately, there is no Linux support, because the library libndofdev doesn’t have a fully finished Linux part.

The simplest solution was to create a drop-in replacement for the library, implementing minimum of the public API in the file ndofdev_external.h distributed with the Second Life sources.

Prerequirements:

  • Working SpaceNavigator according to the instructions above.
  • Ability to build the Second Life client from sources.
  • SDL installed, including the development package (headers).

Steps required to build Second Life with support for joysticks and SpaceNavigator:

  1. Download and build the replacement libndofdev library sources. Just unpack the archive and run make. If everything is OK, a static library libndofdev.a will be created.
  2. Place the resulting library file in the library directory of your Second Life build, most likely somewhere in linden/libraries/i686-linux/lib_release_client
  3. Place the ndofdev_external.h header file together with the other library headers, in my case in linden/libraries/i686-linux/include
    Note: This step is not required for the new development viewer 1.21.x
  4. Modify indra/newview/llviewerjoystick.h to include Linux in the LIB_NDOF macro:
    Replace:
    #define LIB_NDOF (LL_WINDOWS || LL_DARWIN)
    with:
    #define LIB_NDOF (LL_WINDOWS || LL_DARWIN || LL_LINUX)
    Note: This step is not required for the new development viewer 1.21.x
  5. Change the indra/SConstruct to link the Linux build with it, use the SConstruct patch.
    If you are using a Subversion CMake-based build, use this patch, originally based on a contribution from Cam <dnbyena (at) gmail.com>.
  6. Rebuild the viewer as usual. The viewer will auto detect the device when started. Hot plugging is not implemented because it would require DBUS notifications that are not standardized across distros.
  7. The SpaceNavigator behaves a bit differently in Linux than in Windows – namely, do not forget to turn off the “3D Cursor” checkbox in the options! Refer to my settings below.
    spacenavigator settings for SecondLife
    Working settings
  8. Enjoy!

9 thoughts on “3DConnexion SpaceNavigator in Linux”

  1. Scott

    I can’t believe it took so long to find someone with the same frustrated view of the 3DConnexion Linux drivers as I have – I’m glad I’m not the only one on the planet Jan!

    I haven’t yet tried what you suggest, but I was wondering how applications figure out the device – is it as you do: search likely dev names (/dev/input/event) for the right vendor number?

    I’m currently scratching my head in trying to get it to consistently work with Fledermaus (and IVS even ship the driver … albeit an older 1.3). It was bad enough getting the driver to work after a plug/unplug/plug in – the driver wouldn’t restart so would (a) remain owned by the last user and (b) presumably still use the wrong device since udev gives it a new one each time.

    Reply ↓
    1. admin Post author

      Hi Scott,

      The 3DConnexion drivers are indeed terrible, but that is pretty much par for the course for Unix (not only Linux) commercial software 🙁 Their Unix driver seems to be a straight port of a driver for Unix workstations, therefore the dependency on Motif, the requirement to run as root (commercial unices don’t have ACLs on devices nor a way to assign permissions to devices dynamically), etc.

      I have yet to find a hardware company that is capable of producing solid drivers and application software for their products … Usually one or both are junk, even though the hardware is good.

      Regarding the detection of the navigator – I am using enumeration, another possibility is to use libusb to enumerate and talk to the device. Finally, with modern systems it is possible to configure SpaceNavigator as XInput device and use the standard X APIs to access it, the same as you would e.g. a spaceball or tablet. The messy low level stuff like managing permissions and device files is handled by udev and PolicyKit for me.

      The mess you have with the driver is likely a bug in the driver or just crappy code. Have a look at the open source SpaceNav project http://spacenav.sourceforge.net/, their code is supposedly a drop-in replacement for the crummy official driver. Or you can try to convince ISV to dump that thing and just interface the navigator directly (much easier than using the official SDK, IMO).

      Regards,

      Jan

      Reply ↓
  2. martin erikson

    Any idees of how to get the spacemous working in Onshape (linux)?

    Reply ↓
    1. Jan Post author

      No idea, sorry. I am both SpaceNavigator and OnShape user, but unless OnShape devs add support for it, I don’t see how this could be made to work. I assume it needs some sort of server/daemon or a browser plugin to access the device, which are not available for Linux.

      I would suggest asking OnShape support, feel free to point them to me if they need to know how to make SpaceMouse/Navigator work in Linux (3DConnexion doesn’t support Linux any more, I believe).

      Reply ↓
        1. Jan Post author

          Hello,

          Onshape likely expects the official (horribly insecure and generally terrible) 3DConnexion driver (https://www.3dconnexion.com/service/drivers.html). That runs a daemon in the background to which programs that want to use the device try to connect. So you will have to install that, I am afraid. Otherwise you can also try the Spacenav driver (http://spacenav.sourceforge.net/) which uses the same design, it is supposedly a drop-in replacement.

          I am not going to reimplement such a daemon myself because it both exists already and it is a very poor, “not-linuxy” design. The last time I have checked the official driver, the daemon required you to run it as root in order to access the hardware and also needed an open access to your X session too to display its Motif (!) UI. Basically opening two elephant-sized security holes in your system, just to use a mouse/joystick. It was a horrendous port from old commercial Unix from some 20 years ago where this kind of setup was par for the course but that has no place on a modern Linux system connected to the Internet. And given that the last update of this software was in 2014, it speaks volumes about 3DConnexion’s (or, well Logitech’s) support for Linux.

          Now when it comes to OnShape, they don’t have much choice until browsers allow access to USB devices (standardization of that is pending, AFAIK), the only way to give a web app running in a browser like this access to a hardware device not supported by the browser itself (unlike keyboard/mouse/webcam/…) is through some external “bridge” – such as that 3DConnexion daemon. Before it was possible to do such things using browser plugins as well but that possibility is being deprecated and removed by the browser vendors for security reasons. OnShape developers could always make a small helper to run in Linux to work as a go-between between OnShape and the Space Navigator but Linux is probably not high enough on their priority list to bother with it, especially since Windows/Mac don’t need it (because they have saner, officially supported SDK).

          So I don’t think I can help you much here, I am afraid.

          Regards,

          Jan

          Reply ↓
          1. Patola

            Wow. You actually respond to messages 7 years after the post.
            I also have a space navigator that I use in FreeCAD and Blender. Cura, an open-source slicer for 3D printers, has a ticker asking for support of space mouse: https://github.com/Ultimaker/Cura/issues/1152 but it hasn’t been implemented yet. However, a Windows dude was able to achieve that, apparently by mapping input controls: https://www.thingiverse.com/thing:2913885

            I am as of right now trying to see whether spacenavd could translate the space navigator input to keys and mouse, so that it could be output to Cura to achieve the same effect of the driver xml file in Windows. I don’t want to use the proprietary driver (I do not even know if it’s still compatible). Do you have any directions? Should I inspect spacenavd code or there is some clever way to do that via xinput or whatever?

          2. Jan Post author

            Hello,

            If you want to support SpaceNavigator in the Linux version of Cura (or whatever) it is actually very simple even without bothering with stuff like the various demons (spacenavd or the official driver). You don’t need any of it – SpaceNavigator (and its bigger relatives SpaceBall/SpaceMouse) present themselves as a standard USB joystick to Linux so all you have to do is to use the event API. Look at the example spacenavig.c code above, it shows exactly how to read the data from it, both the axes and the buttons. Adding that to Cura would be fairly simple, assuming they have some abstraction (e.g. camera or 3D cursor) that you can control with it.

            I think that is going to be a much better idea than a hackish translation to mouse and keyboard – that is never going to work terribly well because you can’t properly translate a 6DoF device to 2DoF (mouse) + keys. If you have ever tried to control a mouse cursor using a joystick/gamepad, that should give you the idea of how awkward that feels – and that was just 2D movement, not 3D, with 3 translations and 3 rotations, independent of each other. The devices are not used in the same fashion so trying to implement support by reducing the SpaceNavigator to a keyboard/mouse functionality is going to be horrible – first translating from the 6DoF motion to mouse/keys and then in Cura having to “translate” a 2D mouse/key interaction into 3D movement again.

            If you still want to do this pointless hack no matter what, you can use the uinput (not xinput) driver to inject input device messages into the kernel. That will permit you to simulate key presses or mouse movements and the rest of the software stack (Xorg, etc.) will pick them up transparently.
            See here: https://www.kernel.org/doc/html/v4.16/input/uinput.html

  3. Pingback: 3DConnexion mouse problem, how to solve it – Activ Soft

Leave a Reply

Your email address will not be published. Required fields are marked *