[PATCH] evdev and 3DConnexion SpaceTraveler
roland at ccom.unh.edu
Mon Feb 5 17:36:07 PST 2007
This is my first list message, first patch submission, first time using
git and first time hacking Xserver code, so please be gentle with me! :)
Anyways, I have been trying to get my 3DConnexion SpaceTraveler to be
supported by glut like the old SpaceBalls used to be. Fortunately, the
device automatically showed up as an input device when plugged into my
Ubuntu 6.10 box. Here's the relevant section from /proc/bus/input/devices
I: Bus=0003 Vendor=046d Product=c623 Version=0311
N: Name="3Dconnexion SpaceTraveler USB"
B: KEY=ff 0 0 0 0
A few problems surfaced as I tried to configure it as an XInput device
using the evdev driver. Here are the problems and how I dealt with them
in the attached patch.
* The axis are reported as relative, but they should be treated as absolute.
- I simply allowed the "Mode" "Absolute" option to work with relative axes.
* Min and Max values are not made available to XInput, but glut expects
them to be valid.
- I just hard coded the values used in the magellan input driver. (I
probably should have added options for this as well...)
* Glut expects the device to be named "spaceball", not
- I added a "ForceID" option that allows to override the generated name
for the device. I'm assuming the generated name is to prevent name
conflicts, so using this option should be considered risky, and should
only be used if really needed.
* An event was created for each individual axes.
- I added a "Type" option, and if it is set to "Spaceball", state->sync
is set to 1, fixing the problem. It also sets the type_name to
XI_SPACEBALL instead of the default XI_MOUSE.
Here's my resulting xorg.conf entry to make it work:
Option "Name" "3Dconnexion*"
Option "Mode" "Absolute"
Option "ZRelativeAxisButtons" "0 0"
Option "Type" "Spaceball"
Option "ForceID" "spaceball"
This allowed me to move and rotate the dinosaur in the glut dinoball
demo! (Woohoo a working spaceball!!!)
Does this seem like a reasonable way of getting the SpaceTraveler to
work, or is it better to have a separate, specific driver? I suspect
that other devices might have some of the problems I encountered, and
could use the added options, making this patch belong here. On the other
hand, maybe evdev is not meant to get bloated with such special cases.
Either way, what's the best way to make this, or an alternative solution
to supporting 3DConnexion devices part of a future release?
Center for Coastal and Ocean Mapping
University of New Hampshire
Durham, New Hampshire
roland at ccom.unh.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7191 bytes
Desc: not available
More information about the xorg