Space Navigator 3D

[Timothy S. Nelson]

On Mon, 31 Aug 2009, Peter Hutterer wrote:

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

 	Ok, sounds good, except I don't see apps doing this :-/.  What's their 
incentive, when everyone's scroll wheel already works?  Anyway, I'll ask on 
maybe the gtk channel or something.

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

 	Sorry, my mistake -- I only meant to imply that virtual and physical 
could be hooked up in different ways, not that we could go from virtual to 
physical.

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

 	I know people who think xkb is overkill for keyboard maps :).  I guess 
my thoguht was that we could make xkb an all-in-one solution for input 
mapping, so that we could map buttons to keypresses and vice versa.  Also if 
the mouse chording 3-button emulation were generalised we could allow for 
chording keyboards :).  But I guess I should stop getting carried away :).

 	I agree about not implementing it in the driver, though.

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

 	Ok, does it work like this?

-	xkb writes to core tables, ignoring xmodmap
-	xmodmap writes to core tables, ignoring xkb
-	client reads from core tables

 	If there's something that explains all this that I should read, please 
let me know.

 	HTH,


---------------------------------------------------------------------
| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayland at wayland.id.au    | I am                           |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----