Space Navigator 3D
peter.hutterer at who-t.net
Mon Aug 31 21:07:12 PDT 2009
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
>>> - Something that maps a physical axis (scroll wheel) to a virtual set of
>> 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:
>>> ...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
More information about the xorg