Frequently Asked Questions (FAQ)
Table of Contents
- What is spacenav?
- Device driver huh? Do I have to recompile my kernel?
- What's wrong with the driver and SDK provided by 3Dconnexion?
- What is provided by the spacenav project?
- Which platforms are supported?
- Do you plan to support MS Windows too?
- Is this driver only for the "Space Navigator" device?
- The spacenavd daemon is running, but the device LED doesn't turn on.
- Spacenavd starts, but it doesn't generate any events.
- Spacenavd starts, but fails to connect to the X server (xauth errors in /var/log/spnavd.log).
- I've not configured the space navigator as an XInput device but it still won't generate any events
- I've got an old serial maggelan space mouse and it doesn't work.
The spacenav project provides a free, compatible alternative, to the proprietary 3Dconnexion device driver and SDK, for their 3D input devices (called "space navigator", "space pilot", "space traveller", etc).
For more details about 3Dconnexion and their devices: visit their website.
Not really, the linux kernel already provides an interface for USB input devices which adhere to the HID specifications. So, this driver, like the original driver, runs in user-space as a daemon.
The driver provided by 3Dconnexion (a daemon called 3dxserv) has a lot of issues. Some of the most important are the following:
- It is proprietary. See the GNU philosophy page for various articles discussing why this is very bad.
- It supports a very limited number of free UNIX systems. There is only a binary for 32bit x86 GNU/Linux, leaving out of the loop GNU/Linux systems on PowerPC, ARM, and other architectures, plus the multitude of BSD-derived unices.
- Even on x86 GNU/Linux, only two distributions are officially supported: suse and redhat. I'm running Debian, and I never managed to run their driver.
- It has some major design flaws: It only works through the X window system, and more importantly, it depends on motif(?!) for presenting a configuration GUI, and cannot be made to start without it.
The SDK provided by 3Dconnexion (a library called Magellan) also has some important issues:
- It is proprietary (see above) and comes with very restrictive licensing terms.
- It's old and crufty. The interface is ugly, inconsistent, and contains redundant functions. Also, like the proprietary driver, it only works through X11.
This project provides free alternatives to both the 3dxserv daemon, and the magellan library (SDK). The new daemon is called spacenavd and the accompanying library: libspnav.
The spacenavd daemon (replacement driver)
The spacenavd daemon can be used directly as a drop-in replacement. It can communicate with the official magellan SDK, and thus any program compiled with it can work with spacenavd transparently without any change or need of recompilation.
Also, spacenavd provides an alternative communication protocol, for programs that use libspnav, that doesn't require an X server, as the original protocol does.
The libspnav library (replacement SDK)
The libspnav library is provided as a replacement of the magellan library. It provides a cleaner, and more orthogonal interface. libspnav supports both the original X11 protocol for communicating with the driver, and the new alternative non-X protocol. Programs that choose to use the X11 protocol, are automatically compatible with either the free spacenavd driver or the official 3dxserv, as if they were using the magellan SDK.
Also, libspnav provides a magellan API wrapper on top of the new API. So, any applications that were using the magellan library, can switch to libspnav without any changes. And programmers that are familliar with the magellan API can continue using it with a free library without the restrictions of the official SDK.
It's very early in the development of spacenav, and at this point GNU/Linux and Win32 support is implemented. However, the plan is to support any free UNIX system we can get our hands on.
Yes, there is a proof-of-concept driver available, see Windows port.
No. Any current or future USB-based input device from 3Dconnexion should work fine
with this driver. However, some of the extra features of the more expensive models,
like the LCD screen on the Space Pilot, are not supported yet. If you want
to see support for the LCD, feel free to donate a Space Pilot to the project.
The GlobeFish or Aerion device developed by the Bauhaus University of Weimar is also supported by the Windows port. Linux support for this device is on the way.
If you're using an old version of spacenavd (<0.2) or an old linux kernel, the LED won't turn on. However that's not a problem, the device will still function just fine. The LED is not really an indicator, it's only there to make the device look cool.
Make sure you have not configured your X server to communicate with the space navigator through XInput. If you have something like the following in your xorg.conf, and a corresponding "ServerLayout" entry, remove or comment them out:
Section "InputDevice" Identifier "SpaceNav" Driver "evdev" Option "Name" "3Dconnexion SpaceNavigator" Option "Mode" "relative" Option "XRelativeAxisMap" "0" Option "YRelativeAxisMap" "1" Option "ZRelativeAxisMap" "2" Option "RXRelativeAxisMap" "3" Option "RYRelativeAxisMap" "4" Option "RZRelativeAxisMap" "5" Option "ZRelativeAxisButtons" "off" EndSection
We're planning to add XInput support to spacenavd at some future release, but until then, you'll have to choose either spacenavd or XInput. If you want to contribute the necessary changes to make spacenavd to also get XInput events if available, please contact me.
10. Spacenavd starts, but fails to connect to the X server ("failed to open X11 display" error in /var/log/spnavd.log).
This problem manifests itself when spacenavd is started from init, and then you try to call "spnavd_x11 start" to let it know it can go on and connect to the X server (usually from the X init scripts, but even manualy).
Since spacenavd runs as root, you must make sure that root can connect to the X server. The X authentication model depends on MIT-MAGIC-COOKIES, stored in your ~/.Xauthority file. If there isn't an .Xauthority file in the root user's home directory (commonly /root) then you must copy your .Xauthority there, to allow root connect to the X server.
Note that this problem doesn't happen when you just use "su" or "sudo" to gain temporary root priviledges to launch the daemon. That's because the XAUTHORITY environment variable still points to your user's .Xauthority file, not root's.
11. I've not configured the space navigator as an XInput device but it still won't generate any events.
Older versions of spacenavd (<0.4) do not actively grab the device, thus it might be the case that the X server automatically detects the space navigator and tries to use it as an XInput device, which results in the spacenav daemon not getting any USB HID events.
In that case you need to create a HAL fdi policy file, that'll instruct the X server to not try and use the space navigator device. Create a file spacenav.fdi under /etc/hal/fdi/policy/:
<?xml version="1.0" encoding="ISO-8859-1"?> <deviceinfo version="0.2"> <device> <match key="info.product" contains="3Dconnexion"> <remove key="input.x11_driver"/> </match> </device> </deviceinfo>
Thanks to Jaroslaw Bulat for that information
The old serial magellan space mice use a different protocol from the serial spaceballs which are currently supported. This patch adds the necessary functionality to spacenavd, to handle those devices. In the future it will be integrated in the spacenavd source code.
Thanks to Thomas Anderson for providing the patch.