Bug 18715 - evdev no longer works with the SpaceNavigator
Summary: evdev no longer works with the SpaceNavigator
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: 7.3 (2007.09)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Daniel Stone
QA Contact: Xorg Project Team
Depends on:
Reported: 2008-11-26 12:14 UTC by jsado_sc3
Modified: 2013-03-26 05:58 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Patch to get evdev to accept the SpaceNavigator (608 bytes, patch)
2008-11-26 12:14 UTC, jsado_sc3
no flags Details | Splinter Review
lists XInput devices, and does some extra checks if the device name is spaceball (2.85 KB, text/plain)
2008-11-27 17:22 UTC, jsado_sc3
no flags Details
Patch to evdev.c to support the SpaceNavigator 6DOF device. (6.31 KB, patch)
2008-11-29 05:30 UTC, jsado_sc3
no flags Details | Splinter Review
Patch to evdev.c to support the SpaceNavigator 6DOF device. (6.31 KB, patch)
2008-11-29 17:37 UTC, jsado_sc3
no flags Details | Splinter Review

Description jsado_sc3 2008-11-26 12:14:21 UTC
Created attachment 20613 [details] [review]
Patch to get evdev to accept the SpaceNavigator

I have reason to believe that at one point the evdev input driver worked with the SpaceNavigator (www.3dconnexion.com). I only managed to get it to accept the SpaceNavigator after some help from the IRC channel. Here are some web site that mention this input driver in regards to this device:'

http://www.fox-toolkit.org/  (scroll down to the January 2nd entry)

Specifically, the first one mentions upgrading to X.org 7.3, which I did just for this purpose. Well, I kept getting an error in my log stating something to the effect of "Don't know how to use this device", or "Don't know what this is". 

Discussion with a very helpful fellow on the IRC channel brought us to the conclusion that the evdev driver version 2.0.7 that I am running expects to see Btn_Left and Btn_Right, but what is reported is Btn_0 and Btn_1. So he gave me a patch to the appropriate file that allowed it to accept the SpaceNavigator as in input device, and not a core one (not moving the mouse). I will attach this.

I don't think this gets me where I need to be, though. I am trying to get this device to work with GLUT (the OpenGL Utility Toolkit), or really anything that can handle XInput devices (I think GTK can do this also). Although the patch above does allow the device to be recognized, and xidump -l shows the device, it doesn't appear to be registered properly. The axes are not listed. Here is what GLUT is doing to look for the device:

  device_info = XListInputDevices(__glutDisplay, &num_dev);
  if (device_info) {
    for (i = 0; i < num_dev; i++) {
      /* XXX These are SGI names for these devices;
         unfortunately, no good standard exists for standard
         types of X input extension devices. */

      device = &device_info[i];
      any = (XAnyClassPtr) device->inputclassinfo;

      if (!__glutSpaceball && !strcmp(device->name, "spaceball")) {
        v = NULL;
        b = NULL;
        for (j = 0; j < device->num_classes; j++) {
#if defined(__cplusplus) || defined(c_plusplus)
          switch (any->c_class) {
          switch (any->class) {
          case ButtonClass:
            b = (XButtonInfoPtr) any;
            btns = b->num_buttons;
          case ValuatorClass:
            v = (XValuatorInfoPtr) any;
            /* Sanity check: at least 6 valuators? */
            if (v->num_axes < NUM_SPACEBALL_AXIS)
              goto skip_device;
            a = (XAxisInfoPtr) ((char *) v + sizeof(XValuatorInfo));
            for (k = 0; k < NUM_SPACEBALL_AXIS; k++, a++) {
              __glutSpaceballRange[k].min = a->min_value;
              __glutSpaceballRange[k].range = a->max_value - a->min_value;
          any = (XAnyClassPtr) ((char *) any + any->length);
        if (v) {
          __glutSpaceball = XOpenDevice(__glutDisplay, device->id);
          if (__glutSpaceball) {
            __glutNumSpaceballButtons = btns;

When I created a little program to mimic this and see what is going on, I determined that the value of v->num_axes is blank, so I don't think the axes are getting set up on the device within the XInput extension.
Comment 1 Peter Hutterer 2008-11-26 12:44:08 UTC
evdev has seen quite a few changes between 2.0.x and 2.1.0. Please make sure
that you test with 2.1 first and verify the bug still exists (the BTN_0 bug
for example should be fixed).

Please run evtest against the device and attach the output here.
you can get a copy from http://people.freedesktop.org/~whot/evtest.c
Comment 2 jsado_sc3 2008-11-26 13:04:48 UTC
Ok, I'll try evdev 2.1.0. For now here is the output you requested.

> ./evtest /dev/input/spacenav 
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x46d product 0xc626 version 0x110
Input device name: "3Dconnexion SpaceNavigator"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 256 (Btn0)
    Event code 257 (Btn1)
  Event type 2 (Relative)
    Event code 0 (X)
    Event code 1 (Y)
    Event code 2 (Z)
    Event code 3 (?)
    Event code 4 (?)
    Event code 5 (?)
  Event type 4 (Misc)
    Event code 4 (ScanCode)
  Event type 17 (LED)
    Event code 8 (Misc)
Grab succeeded, ungrabbing.
Testing ... (interrupt to exit)
Event: time 1227733419.636784, -------------- Report Sync ------------
Event: time 1227733421.524510, -------------- Report Sync ------------
Event: time 1227733421.532422, type 2 (Relative), code 3 (?), value -1
Event: time 1227733421.532481, -------------- Report Sync ------------
Event: time 1227733421.540453, -------------- Report Sync ------------
Event: time 1227733421.548430, type 2 (Relative), code 3 (?), value -2
Event: time 1227733421.548503, -------------- Report Sync ------------
Event: time 1227733421.556446, -------------- Report Sync ------------
Event: time 1227733421.564568, type 2 (Relative), code 3 (?), value -4
Event: time 1227733421.564627, -------------- Report Sync ------------
Event: time 1227733421.572464, -------------- Report Sync ------------
Event: time 1227733421.580719, type 2 (Relative), code 3 (?), value -7
Event: time 1227733421.580885, -------------- Report Sync ------------
Event: time 1227733421.589230, -------------- Report Sync ------------
Event: time 1227733421.596730, type 2 (Relative), code 3 (?), value -5
Event: time 1227733421.596768, -------------- Report Sync ------------
Event: time 1227733421.604566, -------------- Report Sync ------------
Event: time 1227733421.612390, type 2 (Relative), code 3 (?), value -5
Event: time 1227733421.612417, -------------- Report Sync ------------
Event: time 1227733421.620394, -------------- Report Sync ------------
Event: time 1227733421.628395, type 2 (Relative), code 3 (?), value -2
Event: time 1227733421.628423, -------------- Report Sync ------------
Event: time 1227733421.636392, -------------- Report Sync ------------
Event: time 1227733421.644404, -------------- Report Sync ------------
Comment 3 Daniel Stone 2008-11-26 14:03:16 UTC
i've got one of those, and will look at it after i've moved house.
Comment 4 Peter Hutterer 2008-11-27 14:00:22 UTC
On Wed, Nov 26, 2008 at 01:04:50PM -0800, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #2 from jsado_sc2@comcast.net  2008-11-26 13:04:48 PST ---
> Ok, I'll try evdev 2.1.0. For now here is the output you requested.
> > ./evtest /dev/input/spacenav 
> Input driver version is 1.0.0
> Input device ID: bus 0x3 vendor 0x46d product 0xc626 version 0x110
> Input device name: "3Dconnexion SpaceNavigator"
> Supported events:
>   Event type 0 (Sync)
>   Event type 1 (Key)
>     Event code 256 (Btn0)
>     Event code 257 (Btn1)

The device doesn't announce BTN_LEFT, etc, and evdev 2.0 doesn't know what to
do with it. This bug was fixed with the commit below. Please upgrade to evdev
2.1.0. If the bug still persists, please reopen this bug.

commit 64554e4799a697d37dfd8be480f8eee636b9bea1
Author: Peter Hutterer <peter.hutterer@redhat.com>
Date:   Wed Oct 29 13:50:07 2008 +1030

Treat BTN_[0-2] as LMR buttons if necessary.

Treat BTN_[0-2] as LMR buttons on devices that do not advertise BTN_LEFT,
BTN_MIDDLE, BTN_RIGHT (e.g. 3Dconnexion SpaceNavigator).

Otherwise, treat BTN_[0+n] as button 5+n. Note: This causes duplicate
mappings for BTN_0 + n and  BTN_SIDE + n.

This also fixes a bug where we could end up with negative button numbers after
trying to map BTN_0.

Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Comment 5 jsado_sc3 2008-11-27 17:20:26 UTC
I have upgraded to evdev version 2.1.0, and it does recognize the SpaceNavigator. Unfortunately, it still isn't configured or set up properly in X for GLUT. GLUT is looking for a device with six axes, or valuators. The device doesn't appear to have any axes set up, and 32 buttons (there are only two). I grabbed code from the GLUT library to make a little program that displays this information so that I can see why it isn't working in GLUT. The output of the program is this:

> ./device_list  
Virtual core keyboard
Virtual core pointer
num buttons: 32
num axes: 
Insufficient number of axes

I realize that GLUT is an old library, so it may just be using a deprecated interface. I don't really know X, and have just been winging it. To me, it seems that this device should show up as something with two buttons, and six axes. I will attach my short program.

Thank you for your time.
Comment 6 jsado_sc3 2008-11-27 17:22:10 UTC
Created attachment 20643 [details]
lists XInput devices, and does some extra checks if the device name is spaceball
Comment 7 jsado_sc3 2008-11-28 14:02:54 UTC
Looking at the evdev.c file, it has become rather obvious to me that this driver does not handle six-degree-of-freedom devices. The EvdevProbe function only looks to see if there are REL_X and REL_Y (or ABS_X and ABS_Y) axes, and that it has two buttons. If so, then it is configured as a mouse. The EvDevAddRelClass only creates Valuators for the X and Y axes. There is no code for setting up the device as an XI_SPACEBALL, at least in 2.1.0.

This is odd, as the links I gave when I opened this bug report lead one to believe that this worked at some point. Could the XI_SPACEBALL code been taken out?

I also want to mention that I figured out why my program wasn't outputting the number of axes. I had to typecast to an int first. So I did that and sure enough, the device reports just two axes.

So I am thinking that I might be barking up the wrong tree. There are two other X drivers that might be more relevant to this device: Magellan, and spaceorb. The SDK I downloaded for the SpaceNavigator from 3dconnexion mentions Magellan in its functions and datatypes as a prefix. Though I think this is an older name for the device, and the driver might only be serial (this is USB). I am not sure what a spaceorb is. Might be a device from another company.

There is also spacenavigator.sourceforge.net, but they mention that they do not have an XInput driver yet. I really think I want it to be an XInput driver, so that it can be used in whatever application I am working in, and not have to worry about who's grabbed the device last.

Also, this is supposedly working with Blender, though I haven't gotten it to work. Maybe looking at the Blender code could give me some clues as to how they did this.

So I might come back and hack at the evdev.c code if I can't get the others to work, but this is getting about to the limits of my understanding, and will require some time to figure out. I've never done driver development before.
Comment 8 jsado_sc3 2008-11-29 05:28:47 UTC
I have modified the evdev.c file and I am now at a point where it almost works correctly. The only problem I now have is with the x and y axes. The other four work fine. These two are reporting numbers that appear to be cumulative with the value from the device. When I push the device in one direction and then release it I expect something like this: 0, 1, 4, 10, 20, 14, 7, 3, 0

What I am getting is this: 0, 1, 5, 15, 35, 49, 56, 59

I then have to push the device back in the opposite direction to get the numbers back to zero. Since this is only happening with the x and y axes, I suspect that it has something to do with the device being set up as a mouse. I am not sure what though. I have looked through the evdev.c file and don't see where this is being set up. I have also compared my changes to the magellan driver, and I believe I am doing things just the same as that one.

I will provide my patch to evdev.c for now. Maybe someone might know what needs to be done to fix the x and y axes.
Comment 9 jsado_sc3 2008-11-29 05:30:18 UTC
Created attachment 20688 [details] [review]
Patch to evdev.c to support the SpaceNavigator 6DOF device.
Comment 10 jsado_sc3 2008-11-29 17:37:11 UTC
Created attachment 20694 [details] [review]
Patch to evdev.c to support the SpaceNavigator 6DOF device.

Ok, I have made a few more changes and one of them has fixed the problems with the x and y axes. I just looked at what the magellan and spaceorb drivers were doing and followed suit.

I hope this patch (or a modified one) can be accepted into the driver formally. Now I am thinking that some additional options might be useful, like sensitivity adjustment and such. I am wondering if a new driver ought to be designed separate from evdev. For the time being at least it would be good to have these changes in one official driver.
Comment 11 Daniel Stone 2008-11-29 18:43:25 UTC
thanks for the patch! i'll adapt it next week and see what we can come up with.
Comment 12 Ben Martin 2009-01-15 17:42:01 UTC
Hi, I just tested the id=20694 patch, it seems that with that applied my mouse jumps to the top left of screen and doesn't want to move much from there.

Using version xorg-x11-drv-evdev-2.1.0-1 on Fedora 9 is fine, I actually used 
xorg-x11-drv-evdev-2.1.0-3 for testing the patch, so it is also possible that something changed between -1 and -3 that is causing this, though I think that possibility is somewhat less likely.

The most likely thing is that I've got to change my xorg.conf to make the spacenavigator not interact with the normal X mouse in 2.1.0-3.

# xidump -l
Virtual core keyboard          keyboard
Virtual core pointer           disabled
Keyboard0                      unknown
SpaceNavigator                 unknown
Logitech USB Receiver          unknown
Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) unknown
Logitech USB-PS/2 Optical Mouse unknown
Macintosh mouse button emulation unknown

Section "InputDevice"
        Identifier  "SpaceNavigator"
        Driver      "evdev"
        Option      "Device" "/dev/input/spacenavigator"
        Option      "Mode"   "Absolute"
        Option      "XRelativeAxisMap"  "0"
        Option      "YRelativeAxisMap"  "1"
        Option      "ZRelativeAxisMap"  "2"
        Option      "RXRelativeAxisMap" "3"
        Option      "RYRelativeAxisMap" "4"
        Option      "RZRelativeAxisMap" "5"
        Option      "ZRelativeAxisButtons" "off"
        Option "GrabDevice" "true"
        Option      "SendCoreEvents" "false"
Comment 13 Ben Martin 2009-01-15 18:06:39 UTC
i just tried this with xorg-x11-drv-evdev-2.1.1-1, the patch needed a slight change to apply. even when i disconnect the spave navigator the mouse does the same thing.
Comment 14 jsado_sc3 2009-01-16 17:57:28 UTC
I believe I made the patch against evdev 2.1.0. I'm not sure if this might be part of your problem.

Here is my section of xorg.conf to configure the SpaceNavigator.

Section "InputDevice"
  Identifier "spaceball"
  Driver     "evdev"
  Option     "Device" "/dev/input/spacenav"
  Option     "AlwaysCore" "off"
  Option     "Emulate3Buttons" "off"
  Option     "EmulateWheel"  "off"

Maybe you need the AlwaysCore line.

By the look of your Device line, I suspect you have configured udev correctly, but just to be certain, here is my udev rule:

KERNEL=="event[0-9]" ATTRS{idProduct}=="c626", ATTRS{idVendor}=="046d", NAME="%k", SYMLINK+="input/spacenav", MODE="0666"

Note, if you want to use the SpaceNavigator with a GLUT enabled application, then the Identifier must be "spaceball". GLUT looks for an input device of that name.

Finally, I just want to mention that I no longer have the SpaceNavigator. I was just borrowing it for a little while. So I wont be able to test much out for you until I purchase my own.

I hope this helps.
Comment 15 Peter Hutterer 2010-11-18 20:32:41 UTC
http://www.spinics.net/lists/xorg/msg51274.html may be of interest here. looks like the device works in principle, but the data sent causes a pointer reset.
Comment 16 Peter Hutterer 2013-03-26 05:58:01 UTC
Last update was over 2 years go so I'm going to pretend this has been fixed since. If not, please re-open and submit an evemu recording for this device.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.