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