Hello all,
as simon, stew and Methedras have described, the Space Navigator is easily accessible by Linux applications using the Linux-Input API and devices. However, direct access to input devices has it's own problems, especially concerning device access permissions (has to be handled carefully, to avoid direct access to critical devices like the keyboard ...) and shared access by different applications. Also, things like window-focus handling have to be implemented for GUI applications, since the kernel devices knows nothing about X11.
So I'd like to propose a more abstract (and maybe "cleaner") way to handle things: The Space Navigator gets configured as an input device for X11 (X.Org) and accessed by applications via the XInput API. This is also compatible with the way other special input devices are usually handled, for example GIMP and Blender access graphics tables (e.g. Wacom's) like this. Since X11 handles kernel devices access, there's no permissions to worry about, and things like window-focus dependent input are of course also handled by X11. Plus, by supporting XInput devices (preferably with configurable mapping between inputs and application controls), an application will be usable not only with graphics tablets and 3dconnexion products, but also with lots of other current and future input devices. (The XInput X11 extension is not even specific to Linux and X.Org, other Unix platforms and X11 servers have it, too.)
While X.Org provides no special drivers for 3dconnexion devices, like it does for Wacom tables and similar devices, the Space Navigator can be configured as an X11 input device using the generic evdev driver which is available with current versions of X.Org. X.Org's evdev (not to be confused with the kernel evdev module) acts as a generic wrapper for /dev/input/eventN devices. Devices can be specified using their name, using vendor and product id, and even via their capabilities, so there's no need to know which specific /dev/input/eventN device has been assigned to the Navigator (so no need for symbolic device links).
Here's a sample how set things up in the X.Org config:
/etc/X11/xorg.conf :
-----------------------------------------------------------------------
[...]
Section "ServerLayout"
[...]
InputDevice "spaceball"
EndSection
[...]
Section "InputDevice"
Identifier "spaceball"
Driver "evdev"
Option "Name" "3Dconnexion SpaceNavigator"
Option "Pass" "3"
Option "ZRelativeAxisButtons" "Off"
EndSection
[...]
-----------------------------------------------------------------------
That's all. If you use
InputDevice "spaceball" "SendCoreEvents"
instead, you can move the mouse pointer with your Space Navigator (not very useful, but a nice demo). :-)
Documentation is available here, for example:
http://www.die.net/doc/linux/man/man4/evdev.4.html
You can test the setup with
xidump -l
which will list all XInput devices, and
xidump spaceball-usb-[...]
to show the axes and button values.
xidump is available with the wacom-tools package on Ubuntu, if your distribution does not provide is, you can easily compile it yourself (xidump is quite short and simple, also a nice primer to start using the XInput API).
The devices axes will be relative axes, like with the kernel device. However, unlike the kernel device events which contain the movement steps along a relative axis, XInput events uses cumulative relative axes. A bit peculiar, but harmless: The Space Navigator buttons will show up as buttons 17 and 18, this is because button number assignment is derived from the Linux-Input button and key ID's. evdev will probable provide things like button remapping in the future.
I don't know if you can control the blue LED this way, though. But since it's persistent, you can always enable it directly via the kernel device with a separate program if have need for more light on your desk. :-)