missing init script

Bug #325059 reported by John Tsiombikas
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
spacenavd (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: spacenavd

Hi, I'm the author of spacenavd.
I stumbled accidentally on the ubuntu package (I'm using debian myself), and I installed spacenavd on an ubuntu 8.10 system using the intrepid-backports apt source.

Apparently spacenavd is not set up to start automatically when installed. The source distribution of spacenavd contains an example init script that can be used for that reason, and a shell script (spnavd_ctl) which must be run after the X server is started to let the daemon know it can connect to the X server (spnavd_ctl x11 start).

If you need any further assistance with the ubuntu package of spacenavd please contact me directly: <email address hidden>

Revision history for this message
spliffster (spliffster) wrote :

As followup to the developer's post I would like to document what needs to be done to get a 3donnexion Space Navigator[1] working on ubuntu 9.04 jaunty (might be resolved in later releases) running an 32 bit kernel for blender:

The software itself runs out of the box (install the package spacenavd [version 0.3 comes with jaunty], the open source driver). However, the package itself is incomplete and does not install all needed scripts. Two problems have to be resolved after installing the package to be used, 3 problems to get it work with blender:

1) init script
The init script is missing. The spacenavd must be started during boot. Copy attached spacenavd to /etc/init.d/spacenavd
# chmod 744 /etc/init.d/spacenavd
# chown root:root /etc/init.d/spacenavd

Then create symbolic links to:
# ln -s /etc/init.d/spacenavd /etc/rc2.d/S99spacenavd
# ln -s /etc/init.d/spacenavd /etc/rc2.d/K99spacenavd

Your space Navigator will be initialized now upon boot (blue light should be on after boot).

As a side note to the original developer: The upstram binary package ships with a setup_init script. It will fail on ubuntu since ubuntu is using upstart instead of init. The script will fail to find /etc/inittab because it is not available on an default ubuntu installation (jaunty and later for sure). Unfortunately I haven't discovered how to reliably detect the default runlevel on a system using upstart, maybe some ubuntu devs could help here?

2) X11 Mouse (problem related to hal policy)
By default, the Space Navigator[1] is treatet as touchpad/mouse. This will move the mouse cursor away out of the application (for example blender) when used. the application will loose focus and and the spacenav stops working. An additional hal policy will fix this. Copy no-3dconnexion-trackpoint.fdi (see attachment) to /etc/hal/fdi/policy/no-3dconnexion-trackpoint.fdi and reboot.

After this, my Space Navigator was ready to use with blender. However, blender needed an additional plugin.

3) Install blender plugin (blender only)
Copy 3DxNdofBlender.plug [2] (see Attachment) to ~/.blender/plugins/3DxNdofBlender.plug. If blender was running, you must restart blender.

Kind regards,
-S

Foot notes:
1] Space Navigator is what I have, AFAIK spacenavd does support all devices of 3dconnexion as of 2010-01-11, so this info applies to other devices too.
http://spacenav.sourceforge.net/

2] The official plugin from the 3dconnexion: http://www.3dconnexion.com

Revision history for this message
spliffster (spliffster) wrote :

Jaunty (and later) init script for spacenavd

Revision history for this message
spliffster (spliffster) wrote :

Disable spacenav as X11 mouse/touchpad

Revision history for this message
spliffster (spliffster) wrote :

Blender plugin for 3dconnexion Space Navigator (and simmilar)

Revision history for this message
spliffster (spliffster) wrote :

When the attached spacenavd script is installed under /etc/init.d/spacenavd then the appropriate links in the etc/rc[0-9].d are (under ubuntu/debian) installed best as follows:

# /usr/sbin/update-rc.d -n spacenavd defaults

This could (and probably should) be used in the upstream source package's setup_init script.

Revision history for this message
spliffster (spliffster) wrote :

diff -Nru patch for setup_init (spacenavd version 0.4)

Revision history for this message
spliffster (spliffster) wrote :

debian init script (also for ubuntu) and setup_init (old, new and patch file)

Revision history for this message
Hans Bakker (hansmbakker) wrote :

Maybe an upstart or udev rule to start the daemon would be better?

Revision history for this message
spliffster (spliffster) wrote :

Could be, I don't know much about udev nor upstart. Any suggestions ?

Revision history for this message
John Tsiombikas (nuclear-member) wrote :

Hello again. Glad to see that somebody is trying to resolve this :)

This is just to let you know that I strongly suggest using spacenavd 0.4 as it fixed a lot of the problems of previous versions.

Specifically, it now detects automatically when a supported device is plugged in by monitoring kernel hotplugging events, and it also detects when the X server is started without having to rely on the user to call spnavd_ctl to signal that it's OK to connect to the X server as I mentioned in my first message.

Now as for the setup_init script that comes with spacenavd, that's meant more like an example, and an attempt to help users trying to install the driver from source on a typical GNU/Linux system without assuming anything distribution-specific. I assumed that it wouldn't be used in distribution packages where the packager would be able to set everything up according to each distribution's conventions and idiosyncrasies.

So, feel free to start the daemon using whatever init system ubuntu uses. In this case that would be upstart. I don't think it's a good idea to make a udev rule, because then you'd have to maintain a list of USB devices which are supported by spacenavd, thus duplicating the work done in spacenavd.

Cheers

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.