Linux Support for SpaceNavigator

If you have questions or comments concerning any non-support related 3Dconnexion topic, please use this forum.

Moderator: Moderators

Would you like Linux support on the new SpaceNavigator?

Yes
38
84%
No
5
11%
What's linux?
2
4%
 
Total votes: 45

simon
Posts: 7
Joined: Thu Dec 14, 2006 5:51 pm

Post by simon »

stew: Ah, that is great news.

Methedras: That is great, but unfortunately this seems to no longer work in newer linux kernel (just for the records: Methedras tried this with a 2.6.9 kernel and I had no success with 2.6.19 - looks like a regression in the linux kernel).

I have now experimentally hacked support into one of my eyecandy programs, but will have to work on it to make it feel more natural. I'll make a release, probably in the first week of the new year.

As for locating the space navigator easily: I am using udev and added the following rule to the udev configuration:

Code: Select all

KERNEL=="event[0-9]*", SYSFS{idVendor}=="046d", SYSFS{idProduct}=="c626", SYMLINK+="input/spacenavigator", MODE="0666"
(For Debian testing I created a file /etc/udev/spacenavigator.rules with this line in it and then created a symlink /etc/udev/rules.d/z60_spacenavigator.rules pointing to this file, after restarting udev everything was fine)

This creates a symlink /dev/input/spacenavigator when the spacenavigator is plugged in, it also gets readable for everybody on the computer (it also would be possible to put it in a specific group and add the user using the spacenavigator to this group).
HPW
Posts: 6
Joined: Fri Dec 29, 2006 11:21 am
Location: Germany

Post by HPW »

Methedras,
I have recently started a port to Win2K, using Delphi, which is also basically working.
I would be interested in your Delphi-port because I want to use the device in my delphi-based image-programs.

Would you share that code?
Hans-Peter
bchuertas
Posts: 2
Joined: Tue Nov 28, 2006 1:08 pm

Post by bchuertas »

znissan wrote:Let me put the question out there -- which applications are you all using?

Ziva Nissan
3Dconnexion, Inc.
Autodesk Maya and Apple Shake mainly.
atuor
Posts: 12
Joined: Sun Jan 07, 2007 10:56 am

Post by atuor »

znissan wrote:Let me put the question out there -- which applications are you all using?

Ziva Nissan
3Dconnexion, Inc.

For me Blender unde OpenSuse Linux 10, would be great if you support it ! Blender (be it under Windows or Linux) is a great Modeling software that deserves more support from vendors like you :wink:
simon
Posts: 7
Joined: Thu Dec 14, 2006 5:51 pm

Post by simon »

Update:

I've submitted a patch to make the LED accessible via the linux input system, the patch will hopefully be included in Linux 2.6.20.

The relevant posting to LKML is here: http://lkml.org/lkml/2007/1/15/90 . There also is a patch available for 2.6.19 (and possibly earlier, included in this message: http://lkml.org/lkml/2007/1/14/115

An eyecandy program using the spacenavigator is available at http://www.home.unix-ag.org/simon/files/helix-15.tar.gz . There are udev rules included that you need to incorporate into your configuration to make the program pick up the spacenavigator automatically. Also it is a lot more fun if you have a MIDI device with a lot of knobs :)

The Spacenavigator right now just navigates the view (rotational axes only).

Have fun,
Simon
simon
Posts: 7
Joined: Thu Dec 14, 2006 5:51 pm

Post by simon »

I just got a request via EMail to clarify how the various layers in a Linux System interact. Here's what I wrote (sorry, it is in german), it might be of interest to others as well. This is not necessarily 100% correct, but should give an idea on how the stuff works:

Dein SpacePilot ist ein USB-Gerät, d.h. auf der untersten Ebene findet zwischen Computer und dem Gerät Kommunikation über den USB-Bus statt.

Eine Ebene höher wird ein spezielles Protokoll über den USB-Bus gesprochen, das sogenannte HID (Human Input Device)-Protokoll. Das spezifiziert ein Protokoll, mit dem Geräte dem Computer mitteilen können, welche Funktionalität haben (eine Maus würde z.B. sagen: Ich habe zwei relative Achsen: X- und Y-Richtung, sowie 3 Buttons). Mit dieser Information kann der Computer genau sagen, welche Bedeutung die Daten haben, die da gerade über den Bus kommen.

Der Witz daran ist, dass dieses Protokoll so flexibel ist, dass man *eigentlich* keine weiteren Treiber bräuchte. Man kann einen "alles erschlagenden" Treiber schreiben, der dann *alle* USB-HID-Geräte bedienen kann. (Etwas ähnliches gibt es für USB-Mass Storage-Geräte, USB-Sticks und USB-Festplatten brauchen nicht für jedes Gerät einen eigenen Treiber, sondern nur einen für die gesamte Geräteklasse).

Linux (und Windows natürlich auch) macht genau das: Der Linux-Treiber (den ich gepatcht habe, weil er noch ein paar kleine Fehlerchen hatte) kann genau interpretieren, was mit den Daten gemeint ist.

Nur kommt jetzt noch eine Ebene höher dazu: das Linux Input-System. Der Linux-Kernel abstrahiert nochmal von dem USB-HID und baut noch eine weitere Schicht drüber. Diese ist leider bei weitem nicht so flexibel wie USB-HID, hat aber den Vorteil, dass darunter auch andere (nicht-USB) Geräte erfasst werden können. Also z.B. serielle Mäuse, PS2-Tastaturen, non-USB-Joysticks etc. pp.

Diese Schicht spreche ich mit meinen Programmen an. Die ersten Zeilen die spacenavi ausspuckt zeigen, was bei meinem Programm von dem Eingabegerät ankommt: Also ein paar Buttons und ein paar Achsen (ich gebe nicht alles erkennbare aus, ich könnte auch noch abfragen welche Buttons genau und welche Funktion die Achsen haben). Das ganze ist halt ein schneller Hack, den ich für den SpaceNavigator zusammengebastelt habe.

Unter Umständen ist es aber leider so, dass nicht alle Features eines Geräts über die Linux-Input-Schicht zur Verfügung gestellt werden können. Kandidat wäre zum Beispiel das Text-LC-Display. Dies kann man (wenigstens zur Zeit) noch nicht über das Linux-Input-System nutzen.

Dieser 3dxsrv-Daemon dient dazu, diese Funktionalität zur Verfügung zu stellen (evtl. auch um das Gerät genauer zu konfigurieren und andere Funktionalität bereitzustellen). Weil er das - wie gesagt - nicht über das Linux-Input-System machen kann, muss er eine Ebene tiefer gehen und sich direkt in das USB-Protokoll einklinken.

Dazu muss das Linux-Input-System abgekoppelt werden (das /dev/input/event3 verschwindet) und er sich quasi direkt an die USB-Ebene einklinken (und dann natürlich das HID-Protokoll selber interpretieren). Damit hat der 3dxsrv die volle Kontrolle über das Gerät und kann mit ihm tun und lassen was er will.

Das hat aber natürlich den Nachteil, dass andere Programme - die das Linux-Input-System verwenden - nicht mehr auf den SpaceNavigator zugreifen können und man die Mechanismen des 3dxsrv verwenden *muss* um das Gerät in seinem eigenen Programm verwenden zu können. Wie die allerdings genau aussehen, kann ich - mangels 3dxserv - Dir nicht sagen.

Viele Grüße,
Simon
oliver
Posts: 2
Joined: Wed Feb 07, 2007 1:26 pm

Space Navigator access via XInput instead of kernel HID

Post by oliver »

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. :-)
simon
Posts: 7
Joined: Thu Dec 14, 2006 5:51 pm

Re: Space Navigator access via XInput instead of kernel HID

Post by simon »

oliver wrote: [configuring the SpaceNavigator as XInput-Device]
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.
Right, thanks for the hint, I forgot completely about this. Nice.
However, just because an application supports XInput, that does not mean, that it supports all kinds of devices. For example GIMP can handle XInput tablets, but other devices are completely untested. And if your SpaceNavigator moves the mouse pointer around this is usually not what you want, so better avoid the SendCoreEvents option...
Apropos GIMP: It has a Linux Input controller module that you can enable in the preferences. Since the Chaos Communication Congress this also fully supports the relative axes of the SpaceNavigator, although the support has been improved just today - so get the current SVN if you want to play with it. This also supports joysticks and other linux input devices.
(For the records: There is also a controller module for MIDI devices, which actually is quite fancy - use the knobs on your MIDI-Keyboard to control colors, brush size etc... :)
Regarding Blender: I found a Bug report dealing with 6d-input devices. I have not yet played with it myself, but it sounds promising - people are actually using their SpaceNavigators with it (not sure on what platform though): http://projects.blender.org/tracker/ind ... 9&atid=127

Bye,
Simon
oliver
Posts: 2
Joined: Wed Feb 07, 2007 1:26 pm

Re: Space Navigator access via XInput instead of kernel HID

Post by oliver »

simon wrote: However, just because an application supports XInput, that does not mean, that it supports all kinds of devices. For example GIMP can handle XInput tablets, but other devices are completely untested. And if your
Sady, that's very true. Gimp for example does detect the Space Navigator (configured as an XInput device), and you can assign it's axes, but the buttons don't get detected and you can't do anything useful with it. I hope applications like Gimp will allow for a much more flexible input configuration in the future. After all, you don't have to support specific XInput devices, you just have to provide a way to assign arbitrary XInput axes and buttons to application actions and controls.
simon wrote: SpaceNavigator moves the mouse pointer around this is usually not what you want, so better avoid the SendCoreEvents option...
Yes, of course, that was just intended to show that the Navigator can be used as a true X11 input device - normally, you don't want to move the mouse pointer with the Navigator, of course. :-)
simon wrote: Apropos GIMP: It has a Linux Input controller module that you can enable in the preferences. Since the Chaos Communication Congress this also
Nice, thanks, i'll certainly try it. Can you use the Navigator for panning and zooming in GIMP this way?
simon wrote: Regarding Blender: I found a Bug report dealing with 6d-input devices. I http://projects.blender.org/tracker/ind ... 9&atid=127
I've stumbled onto this myself. I've played a bit with the patch code provided there - it's for Windows, currently (but basically cross-platform), and won't do anything useful without the 3dconnexion driver. The patch does two things: Firstly, it introduces 6DoF input events (class GHOST_EventNDOF) into blender, and makes them change the view, provides preferences for them, etc.. Secondly, it provides a plugin interface to generate these events based on input by a separate plugin. This was done for licensing reasons, only the plugin links against the 3dconnexion API (not GPL compatible), so Blender stays free of such code.
The Blender patch does compile under Linux with small modifications, however, the plugin interface is currently only effective with the windows-specific GUI code. However, the 6DoF-event part of the patch might useful for Linux, too: Since Blender already supports XInput events (limited to tablets at the moment, i believe), it shouldn't be too hard to extend that code, so that Navigator-Style devices are recognised too, and so that Blender GHOST_EventNDOF events are emitted based on their input. The bug-report's patch will then do the rest, i think.
This way, we could get Blender support for the Space Navigator under Linux without a plugin, and completely GPL, but compatible with the way the patch does it for Windows.
Absum
Posts: 53
Joined: Tue Apr 24, 2007 4:00 am
Location: Sweden
Contact:

Post by Absum »

I've tried the suggestions here using udev and xinput to get my spacenavigator recognized by linux, x11 and applications without the use of the 3dconnexion driver. But one thing that i noticed was that when i configured the device in xorg.conf using the vendor and product id as identification instead of the name or device (created with udev) my whole xinput system freaks out, if i have set "SendCoreEvents" my mouse pointer is controlled by the spacenav and my keyboard is messed up, down is print screen and end is mod_4. And when i dont have "SendCoreEvent" no input works... at all.
Keith_Beef
Posts: 3
Joined: Tue Jan 08, 2008 8:12 pm

Re: Space Navigator access via XInput instead of kernel HID

Post by Keith_Beef »

oliver wrote:
simon wrote: However, just because an application supports XInput, that does not mean, that it supports all kinds of devices. For example GIMP can handle XInput tablets, but other devices are completely untested. And if your
Sady, that's very true. Gimp for example does detect the Space Navigator (configured as an XInput device), and you can assign it's axes, but the buttons don't get detected and you can't do anything useful with it. I hope applications like Gimp will allow for a much more flexible input configuration in the future. After all, you don't have to support specific XInput devices, you just have to provide a way to assign arbitrary XInput axes and buttons to application actions and controls.
simon wrote: SpaceNavigator moves the mouse pointer around this is usually not what you want, so better avoid the SendCoreEvents option...
Yes, of course, that was just intended to show that the Navigator can be used as a true X11 input device - normally, you don't want to move the mouse pointer with the Navigator, of course. :-)
simon wrote: Apropos GIMP: It has a Linux Input controller module that you can enable in the preferences. Since the Chaos Communication Congress this also
Nice, thanks, i'll certainly try it. Can you use the Navigator for panning and zooming in GIMP this way?
simon wrote: Regarding Blender: I found a Bug report dealing with 6d-input devices. I http://projects.blender.org/tracker/ind ... 9&atid=127
I've stumbled onto this myself. I've played a bit with the patch code provided there - it's for Windows, currently (but basically cross-platform), and won't do anything useful without the 3dconnexion driver. The patch does two things: Firstly, it introduces 6DoF input events (class GHOST_EventNDOF) into blender, and makes them change the view, provides preferences for them, etc.. Secondly, it provides a plugin interface to generate these events based on input by a separate plugin. This was done for licensing reasons, only the plugin links against the 3dconnexion API (not GPL compatible), so Blender stays free of such code.
The Blender patch does compile under Linux with small modifications, however, the plugin interface is currently only effective with the windows-specific GUI code. However, the 6DoF-event part of the patch might useful for Linux, too: Since Blender already supports XInput events (limited to tablets at the moment, i believe), it shouldn't be too hard to extend that code, so that Navigator-Style devices are recognised too, and so that Blender GHOST_EventNDOF events are emitted based on their input. The bug-report's patch will then do the rest, i think.
This way, we could get Blender support for the Space Navigator under Linux without a plugin, and completely GPL, but compatible with the way the patch does it for Windows.
Keith_Beef
Posts: 3
Joined: Tue Jan 08, 2008 8:12 pm

Re: Space Navigator access via XInput instead of kernel HID

Post by Keith_Beef »

Keith_Beef wrote:
oliver wrote:
simon wrote:...big snip...
The phpBB software "lost" the post that I had carefully crafted, and when I tried to use the "back" button, I ended up submitting a straight quote, without the text I had typed. Grrrr....

anyway, I had given a lengthy explanation of my attempts to get my spaceNavigator working in Gimp, but I'll just direct you to Ubuntu Forums, instead.

http://ubuntuforums.org/showpost.php?p= ... ostcount=8

Beef.
jwick
Moderator
Moderator
Posts: 3331
Joined: Wed Dec 20, 2006 2:25 pm
Location: USA
Contact:

Post by jwick »

Hi Beef,

Good work! (I've been bit by that "don't ever use back" button myself.)

re:
how can I find a list of the events for this controller, with a match to a physical movement?
If you are asking about the directions of the data coming from the device, the raw data is in the following order (the Linux kernel code may rearrange it YMMV):
Axis 1 Pan left or right (equivalent to MouseX)
Axis 2 Pan toward you or away from you (equivalent to MouseY)
Axis 3 Pan up toward the ceiling or down toward the floor
Axis 4 Rotate like a motorcycle throttle
Axis 5 Rotate like a door knob
Axis 6 Rotate like opening a jar of peanut butter

Let us know if that is not what you have found.

Jim
3Dx Software Development
ubald
Posts: 1
Joined: Thu Apr 17, 2008 5:22 pm
Location: Canada, Québec

Post by ubald »

I ave been able to install the space navigator tho I need to kill the /etc/3DxWare/daemon/3dxsrv -d usb each time I connect the device it work for the ./xcube and the other ! Ther is only a big problem :roll: I can't get it to work with Blender I thought it was supported !!!

I'm on linux debian etch (stable!!) The blue light works and the example too but. I bought it in order to use it on blender and possibly on CAD system when I will buy one !

I thought it bee cool to use as input in programing too !

Can any one help me for blender ?? :D

Anny one ave the source for the ./xvalue ?

Merci de votre aide !
user82
Posts: 5
Joined: Sat Jun 14, 2008 1:27 pm

Post by user82 »

I think it's really working fine
Post Reply