3DConnexion SpaceNavigator in Linux

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.


  • 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:
    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!


  • Scott commented on August 25, 2010 Reply

    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.

    • admin commented on August 26, 2010 Reply

      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).



  • martin erikson commented on March 27, 2017 Reply

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

    • Jan commented on March 27, 2017 Reply

      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).

Leave a Reply

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