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) http://www.3dconnexion.com/forum/viewtopic.php?start=15&t=34 http://www.fedorawiki.de/index.php/SpaceNavigator 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) { #else switch (any->class) { #endif case ButtonClass: b = (XButtonInfoPtr) any; btns = b->num_buttons; break; 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; } break; } any = (XAnyClassPtr) ((char *) any + any->length); } if (v) { __glutSpaceball = XOpenDevice(__glutDisplay, device->id); if (__glutSpaceball) { __glutNumSpaceballButtons = btns; addDeviceEventParser(); } } 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.
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
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 ------------ ^C
i've got one of those, and will look at it after i've moved house.
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>
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 Mouse0 Mouse1 Keyboard0 spaceball 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.
Created attachment 20643 [details] lists XInput devices, and does some extra checks if the device name is spaceball
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.
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.
Created attachment 20688 [details] [review] Patch to evdev.c to support the SpaceNavigator 6DOF device.
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.
thanks for the patch! i'll adapt it next week and see what we can come up with.
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 /etc/X11/xorg.conf 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" EndSection
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.
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" EndSection 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.
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.
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. http://wiki.freedesktop.org/wiki/Evemu
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.