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: [email protected] | 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-----
_______________________________________________
xorg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xorg
