Space Navigator 3D

[Peter Hutterer]

On Mon, Aug 31, 2009 at 05:37:44PM +1000, Timothy S. Nelson wrote:
> 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 :).

XKB balances on the tight space between overkill and too little (ask the
input methods guys).

Yes, a lot of things could be added to XKB and a fair number of things could
possibly be removed. but dabbling with XKB is hard and requires a lot of
time to get the big picture right.

and, quite frankly, there's a couple of things that need serious cleaning up
and fixing before we can tack on special needs like this one.

> 	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

used to be that way, 1.7 squashes both together so that there's only one
table in the server - the xkb one. the problem though is that you have to
convert back to a core-compatible format for core clients and then convert
back to xkb if they change something.

> -	client reads from core tables



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

there isn't really, not past the protocol spec. it's (well) hidden in server
code.

Cheers,
  Peter