Space Navigator 3D

[Peter Hutterer]

On Mon, Aug 31, 2009 at 03:20:06PM +1000, Timothy S. Nelson wrote:
> On Mon, 31 Aug 2009, Peter Hutterer wrote:
>
>> On Mon, Aug 31, 2009 at 01:11:54PM +1000, Timothy S. Nelson wrote:
>>>> On Mon, Aug 31, 2009 at 09:13:01AM +1000, Timothy S. Nelson wrote:
>>>>> I have a pointing device with 5 axes (a Space Navigator).  Does anyone
>>>>> know how I can assign one of them to be a scroll wheel?
>>>>
>>>> provided that the space navigator gives you x/y axes and you're running
>>>> evdev from master, enable wheel emulation on button 0.
>>>
>>> 	Hmm.  Like this?
>>>
>>> Device '3Dconnexion SpaceNavigator':
>>> 	Device Enabled (133):	1
>>> 	Evdev Reopen Attempts (266):	10
>>> 	Evdev Axis Inversion (267):	0, 0
>>> 	Evdev Axis Calibration (268):
>>> 	Evdev Axes Swap (269):	0
>>> 	Evdev Middle Button Emulation (270):	2
>>> 	Evdev Middle Button Timeout (271):	50
>>> 	Evdev Wheel Emulation (272):	1
>>> 	Evdev Wheel Emulation Axes (273):	0, 0, 4, 5
>>> 	Evdev Wheel Emulation Inertia (274):	0
>>> 	Evdev Wheel Emulation Timeout (275):	200
>>> 	Evdev Wheel Emulation Button (276):	0
>>> 	Evdev Drag Lock Buttons (277):	0
>>>
>>> 	Because I still get mouse movements when I do that.
>>
>> set the inertia to 10 or something like that. not sure how you ended up with
>> 0, that's not a valid value.
>
> 	Sorry, that's my fault.  I tried it both ways.
>
>> other than that it looks alright. remember that
>> you need evdev from git, evdev 2.2 doesn't allow it.
>
> 	Ok, that explains it then.  I'm on 2.2.4.
>
>>>> tis turns every motion into a scroll wheel event.
>>>
>>> 	Hmm.  But I want to map two of the axes to mouse movements, and two to
>>> scroll.  Can that be done?
>>
>> not yet, sorry. scroll handling is a bit weird, due to the requirement that
>> it is converted into button events before posting. the driver has the wheel
>> axes hardcoded. it'd be possible to add a configuration option for that but
>> you'd have to write the patch yourself. it's not that hard, but it requires
>> lots of testing to make sure it doesn't interfere with other button and axis
>> mappings.
>
> 	Have we considered the possibility of mapping things using an xkb-like  
> set of config files?  Or even integrating it into xkb?  I note that we 
> have:
> -	Something that maps a physical axis (scroll wheel) to a virtual set of
> 	buttons

I'm not sure if this is the right solution.
The reason why scroll wheels are mapped to buttons 4-7 is that the core
protocol didn't allow a third and forth axis. XInput sort-of addressed this
but had a different focus and remained essentially unused bar tablet support.

now we have the infrastructure (mostly) in place so a better approach would
be to fix applications to interpret additional axes as the user wants. this
can then be on a per-application basis, etc.

> -	Something that maps virtual buttons to physical buttons

mapping virtual buttons to physical buttons - we already have that, albeit
the other way round. you can map physical button 1 to logical button 3
(think left-handed mouse) why would we need a mapping virtual button to
physical buttons? 

> -	Things that invert and swap axes

a simple axis mapping similar to the button mapping should suffice, and a
couple of additional flags for inversion.

> 	I don't see any reason why these couldn't be done in an xkb-like  
> fashion, although in the second and third cases, these might need to be  
> implemented in the driver instead of via xmodmap (assuming I understand  
> xmodmap correctly).

xkb is overkill for fairly simple functionality like this. implementing it
in the driver leads to duplications. which isn't that great either. ideally,
this would be supported in the DIX.

> 	Am I correct in understanding that, in this diagram:
>
> http://computerstuff.jdarx.info/content/keystroke-flow-xorg
>
> 	...the xmodmap program also affects the dark green box (possibly at the 
> point where the word "compiles" appears)?

(this page is currently down so I'm looking at the google cache)
anyway, xmodmap tweaks the core tables, not the XKB ones. so it can be
place squarely into the white (== unchartered territory) area of the Server
box. interactions between core tables and XKB is tricky at the best of times
and even undefined for a few cases.

Cheers,
  Peter