[PATCH] evdev and 3DConnexion SpaceTraveler

[Zephaniah E. Hull]

On Mon, Feb 05, 2007 at 08:36:07PM -0500, Roland Arsenault wrote:
> Hello all,
> 
> 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! :)

I'll try. :)
> 
> 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"
> P: Phys=usb-0000:00:02.0-5/input0
> S: Sysfs=/class/input/input7
> H: Handlers=event3
> B: EV=7
> B: KEY=ff 0 0 0 0
> B: REL=3f
> 
> 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.

This part simply isn't going to get into xf86-input-evdev, it's just
plain too evil at the moment.

See the other reply, this should probably be fixed in the kernel driver
for it.
> 
> * 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...)

Not a bad idea, but it's the wrong approach, I'll see about a better
approach soonish.
> 
> * Glut expects the device to be named "spaceball", not 
> "spaceball-some-other-stuff"
> 
> - 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.

Fix glut, looking for a specificly named input device with no
configuration ability is an application/library bug, not a driver issue.

(Yeah, harsh, but I feel strongly about it.)
> 
> * 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.

Not quite right, the kernel is not reporting sync reports, so we
shouldn't be waiting for them.

What kernel version are you using?  I'm fairly sure that the entire
2.6.x line should be handling that properly.

That said, an override to allow overriding the default login for
type_name makes sense, I'll see about a different patch to support that.

...

> 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?

Some of this is reasonable, some should be implemented differently, but
some of it is not going to happen in xf86-input-evdev.

Zephaniah E. Hull.

-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp at aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

ALL programs are poems, it's just that not all programmers are poets.
                -- Jonathan Guthrie in the scary.devil.monastery
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20070206/83ee38ed/attachment.pgp>